[BoostCourse] Web - REST API

[BoostCourse] REST API

 1. REST API의 등장

  - 클라이언트의 종류가 웹 브라우저, 안드로이드 앱, IOS 앱 등 다양해지면서 이러한 클라이언트들에게 정보를 제공하는 방식을 하나로 일원화시키려 했다.

  - 일원화시키는 방식 중에 대표적인 방식이 HTTP 프로토콜로 API를 제공하는 것이다.

  - HTTP 프로토콜로 제공하는 API를 REST API라고 한다.

 2. API의 개념

  - Application Programming Interface의 약자

  - 어떠한 기능을 구현하기 위해 정리해놓은 라이브러리 (function)

  - 응용프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스

 3. REST API란?

  - REST 형식의 API

  - 핵심 컨텐츠 및 기능을 외부 사이트에서 활용할 수 있도록 제공되는 인터페이스

그래서 REST 방식이란건 뭔데? 

 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는 정보의 자원을 표현해야 한다. (리소스명은 동사보다는 명사를 사용)

GET /member/delete/1

  2) 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)로 표현

DELETE /members/1

* 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/