[api] API, 그리고 REST API란?

▼API란?

• 합의된 API 목록에 따라 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘으로, 소프트웨어끼리 소통하는 법이자 데이터를 주고 받기 위한 방법.
• ‘약속된 신호’
• Application Programming Interface

출처 : wishket (맨 아래 참고)

• API는 손님(프로그램)이 주문할 수 있게 메뉴(명령 목록)를 정리하고, 주문(명령)을 받으면 요리사(응용프로그램)와 상호작용하여 요청된 메뉴(명령에 대한 값)를 전달합니다.
• 쉽게 말해, API는 프로그램들이 서로 상호작용하는 것을 도와주는 매개체로 볼 수 있습니다.

 

 

▼ API의 역할은? 

1. API는 서버와 데이터베이스에 대한 출입구 역할을 한다.
   데이터베이스에는 소중한 정보들이 저장되는데요. 모든 사람들이 이 데이터베이스에 접근할 수 있으면 안 되겠지요. API는 이를 방지하기 위해 여러분이 가진 서버와 데이터베이스에 대한 출입구 역할을 하며, 허용된 사람들에게만 접근성을 부여해줍니다.
2.  API는 애플리케이션과 기기가 원활하게 통신할 수 있도록 한다.
   여기서 애플리케이션이란 우리가 흔히 알고 있는 스마트폰 어플이나 프로그램을 말합니다. API는 애플리케이션과 기기가 데이터를 원활히 주고받을 수 있도록 돕는 역할을 합니다.
3. API는 모든 접속을 표준화한다.
   API는 모든 접속을 표준화하기 때문에 기계/ 운영체제 등과 상관없이 누구나 동일한 액세스를 얻을 수 있습니다. 쉽게 말해, API는 범용 플러그처럼 작동한다고 볼 수 있습니다.

 

 

 

▼ REST(REpresentational State Transfer)란?

• HTTP에서 필요한 자원에 접근할 때 웹의 장점을 최대한 활용하기 위한 아키텍처

 

 

▼ REST API란?

• 개발자 사이에서 보편적으로 공유되는 방식
• HTTP 규약에 따라 신호를 전송 (HTTP의 메소드 중 GET, POST, DELETE, PUT, PATCH 사용)
• Roy Thomas Fielding의 박사학위 논문에서 최초로 소개됨 - 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다고 한다.

 

 

▼ REST API의 구성요소

1. HTTP Method - 행위(Verb)
   1. GET : 데이터 조회
   2. POST : 새로운 데이터 추가
   3. PUT : 데이터 전체 수정
   4. PATCH : 데이터 일부 수정
   5. DELETE : 정보 삭제
2. URL - 자원(RESOURCE) / 데이터 접근
3. Representation - 자원의 표현

 

 

▼ REST API 의 특징

1) Uniform (유니폼 인터페이스)
Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다.

2) Stateless (무상태성)
REST는 무상태성 성격을 갖는다. 다시 말해 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다. 세션 정보나 쿠키정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 된다. 때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다.

3) Cacheable (캐시 가능)
REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능하다. 따라서 HTTP가 가진 캐싱 기능이 적용 가능하다. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.

4) Self-descriptiveness (자체 표현 구조)
REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것이다.

5) Client - Server 구조
REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 된다.

6) 계층형 구조
REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.

 

 

▼ REST API의 자원 표현을 위한 URL 설계 규칙 (권장사항)

1. URI는 정보의 자원을 표현해야 한다. (리소스명은 동사보다는 명사를 사용)
2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)로 표현
3. 소문자만 사용
4. 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용 - /animals/mammals/whales
5. URI 마지막 문자로 슬래시(/)를 포함하지 않는다. - /houses/apartments/ (X)
6. 언더바(_)는 쓰지 않고, 필요시 하이픈(-)을 쓰되 지양함
7. 확장자를 표시하지 않음

 

 

▼ HTTP 응답 상태 코드

→ 잘 설계된 REST API는 URI만 잘 설계된 것이 아닌 그 리소스에 대한 응답을 잘 내어주는 것까지 포함되어야 한다. 

 

상태코드
200	클라이언트의 요청을 정상적으로 수행함
201	클라이언트가 어떠한 리소스 생성을 요청, 해당 리소스가 성공적으로 생성됨(POST를 통한 리소스 생성 작업 시)

 

상태코드
400	클라이언트의 요청이 부적절 할 경우 사용하는 응답 코드
401	클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청했을 때 사용하는 응답 코드
	(로그인 하지 않은 유저가 로그인 했을 때, 요청 가능한 리소스를 요청했을 때)
403	유저 인증상태와 관계 없이 응답하고 싶지 않은 리소스를 클라이언트가 요청했을 때 사용하는 응답 코드
	(403 보다는 400이나 404를 사용할 것을 권고. 403 자체가 리소스가 존재한다는 뜻이기 때문에)
405	클라이언트가 요청한 리소스에서는 사용 불가능한 Method를 이용했을 경우 사용하는 응답 코드

 

상태코드
301	클라이언트가 요청한 리소스에 대한 URI가 변경 되었을 때 사용하는 응답 코드
	(응답 시 Location header에 변경된 URI를 적어 줘야 합니다.)
500	서버에 문제가 있을 경우 사용하는 응답 코드

 

 

 

 

 

 

 

 

[참고] https://www.youtube.com/watch?v=X4DezEXbc5o 

[참고] wishket

API란? 비개발자가 알기 쉽게 설명해드립니다! - wishket

[참고] https://meetup.toast.com/posts/92

REST API 제대로 알고 사용하기 : NHN Cloud Meetup