[BoostCourse] REST API
1. REST API의 등장
- 클라이언트의 종류가 웹 브라우저, 안드로이드 앱, IOS 앱 등 다양해지면서 이러한 클라이언트들에게 정보를 제공하는 방식을 하나로 일원화시키려 했다.
- 일원화시키는 방식 중에 대표적인 방식이 HTTP 프로토콜로 API를 제공하는 것이다.
- HTTP 프로토콜로 제공하는 API를 REST API라고 한다.
2. API의 개념
- Application Programming Interface의 약자
- 어떠한 기능을 구현하기 위해 정리해놓은 라이브러리 (function)
- 응용프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스
3. REST API란?
- REST 형식의 API
- 핵심 컨텐츠 및 기능을 외부 사이트에서 활용할 수 있도록 제공되는 인터페이스
4. REST의 특징 및 스타일 (제약조건)
- client-server
- stateless
- cache
- uniform interface **
- layered system
- code-on-demand (optional)
위 해당 사항을 지킨 API만이 RESTful API이다.
** HTTP 프로토콜을 사용하면 위 조건을 충족시킬 수는 있으나 문제는 uniform interface의 조건은 충족하기 어렵다. **
uniform interface의 스타일
- 리소스가 URI로 식별되어야 한다.
- 리소스를 생성, 수정, 추가하고자 할 때, HTTP메시지에 표현(GET, PUT, POST, DELETE) 을 해서 전송해야 한다.
- 메시지는 스스로 설명할 수 있어야 한다. (Self-descriptive message)
- 애플리케이션의 상태는 Hyperlink를 이용해 전이되야 한다. (HATEOAS)
* HATEOAS: 웹 페이지 자체에 관련된 링크가 있는 것을 말한다.
5. REST 구성
- 자원(Resource) - URI
- 행위(Verb) - HTTP METHOD
- 표현(Representations)
6. REST API 디자인 가이드
1) URI는 정보의 자원을 표현
2) 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.
6-1. REST API 중심 규칙
1) URI는 정보의 자원을 표현해야 한다. (리소스명은 동사보다는 명사를 사용)
2) 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)로 표현
* HTTP Method
Method | 역할 |
POST | POST를 통해 해당 URI를 요청하면 리소스를 생성 |
GET | GET를 통해 해당 리소스를 조회, 리소스 조회 후 해당 도큐먼트에 대한 자세한 정보를 가져온다. |
PUT | PUT를 통해 해당 리소스를 수정 |
DELETE | DELETE를 통해 리소스를 삭제 |
* URI는 자원을 표현하는데 집중, 행위에 대한 정의는 HTTP Method를 이용하는 것이 REST API를 설계하는 중심 규칙
6-2. URI 설계 시 주의할 점
1) 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용
2) URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
3) 하이픈(-)은 URI 가독성을 높이는데 사용
4) 밑줄(_)은 URI에 사용하지 않는다.
5) URI 경로에는 소문자가 적합
6-3 리소스 간의 관계를 표현하는 방법
GET /users/{userid}/devices
GET /users/{userid}/likes/devices
6-4 자원을 표현하는 Collection과 Document
http:// restapi.example.com/sports/soccer
http:// restapi.example.com/sports/soccer/players/13
7. HTTP 응답 상태 코드
상태코드 | |
200 | 클라이언트의 요청을 정상적으로 수행 |
201 | 클라이언트가 어떠한 리소스 생성을 요청, 해당 리소스가 성공적으로 생성됨
(POST를 통한 리소스 생성 작업 시) |
400 | 클라이언트의 요청이 부적절할 경우 사용 |
401 | 클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청했을 때 사용 (로그인 하지 않은 유저가 로그인 했을 떄, 요청 가능한 리소스를 요청 했을 때) |
403 | 유저 인증상태와 관계 없이 응답하고 싶지 않은 리소스를 클라이언트가 요청했을 때 사용하는 응답 코드 (403보다는 400이나 404을 사용할 것을 권고, 403 자체가 리소스가 존재한다는 뜻이기 때문) |
405 | 클라이언트가 요청한 리소스에서는 사용 불가능한 Method를 이용했을 경우 사용하는 응답 코드 |
301 | 클라이언트가 요청한 리소스에 대한 URI가 변경되었을 때 사용하는 응답 코드 (응답 시 Location Header에 변경된 URI를 적어 줘야 함) |
500 | 서버에 문제가 있을 경우 사용하는 응답 코드 |
* 참고
https://ko.wikipedia.org/wiki/REST
https://meetup.toast.com/posts/92
https://www.edwith.org/boostcourse-web/lecture/16740/
