진정한 REST

REST ( Representational State Transfer )

• 논문 저자 : Roy T. Fielding
• 현재 상태 : REST API가 아니지만 REST API라고 부른다.

<정의 >

• a way of providing interoperability between computer systems on the internet.
• Architecture Styles and the Design of Network-based Software Architecture
• REST APIs must be hypertext-driven “REST API를 위한 최고의 버저닝 전략은 버저닝을 안 하는 것”

---

<REST를 구성하는 스타일 >

• client-server
• stateless
• cache
• uniform interface
• layered system
• code-on-demand (optional)

---

<Uniform Interface 의 제약 조건 >

• 목표 : 서버와 클라이언트의 독립적인 진화 ( 서버의 API 스펙이 변경되더라도 클라이언트이 업데이트가 필요하지 않도록 )
• 3, 4번이 잘 지켜지지 않는다. (Github API 가 가장 잘 지킨다. )

1. identification of resources
2. manipulation of resources through representation
3. self-descriptive messages
   • 확장 가능한 커뮤니케이션
   • 서버나 클라이언트가 변경되더라도 오고가는 메세지는 언제나 self-descriptive 하므로 언제나 해석 가능
4. hypermedia as the engine of application state (HATEOAS)
   • 애플리케이션의 상태는 Hyperlink 를 이용해 전이되어야 한다
   • 애플리케이션 상태 전이의 late binding
   • 어디서 어디로 전이가 가능한지 미리 결정되지 않는다. 어떤 상태로 전이가 완료되고 나서야 그 다음 전이될 수 있는 상태가 결정된다. 쉽게 말해서 [링크는 동적으로 변경될 수 있다]

---

<REST API >

1. Media Type
   (1) 미디어 타입을 하나 정의한다.
   (2) 미디어 타입 문서를 작성한다. 이 문서에 “id”가 뭐고 “title”이 뭔지 의미를 정의한다.
   (3) IANA에 미디어 타입을 등록한다. 이 때 만든 문서를 미디어 타입의 명세로 등록한다.
   (4) 이제 이 메세지를 보는 사람은 명세를 찾아갈 수 있으므로 이 메세지의 의미를 온전히 해석할 수 있다.

2. Profile
   (1) “id”가 뭐고 “title”이 뭔지 의미를 정의한 명세를 작성한다.
   (2) Link 헤더에 profile relation 으로 해당 명세를 링크한다.
   (3) 이제 이 메세지를 보는 사람은 명세를 찾아갈 수 있으므로 이 문서의 의미를 온전히 해석할 수 있다.
   단점 : 클라이언트가 Link 헤더(RFC 5988)와 profile(RFC 6906)을 이해해야 한다.
   Content negotiation을 할 수 없다.

3. data
   (1) data에 다양한 방법으로 하이퍼링크를 표현한다.
   (2) JSON으로 하이퍼링크를 표현하는 방법을 정의한 명세들을 활용한다.
   - JSON API - HAL - UBER - Siren - Collection+json

4. HTTP 헤더
   (1) Link, Location 등의 헤더로 링크를 표현한다.

---

<정리 >

1. 오늘날 대부분의 “REST API”는 사실 REST를 따르지 않고 있다.
2. REST의 제약조건 중에서 특히 Self-descriptive와 HATEOAS를 잘 만족하지 못한다.
3. REST는 긴 시간에 걸쳐(수십년) 진화하는 웹 애플리케이션을 위한 것이다.
4. REST를 따를 것인지는 API를 설계하는 이들이 스스로 판단하여 결정해야한다.
5. REST를 따르겠다면, Self-descriptive와 HATEOAS를 만족시켜야한다.
   • Self-descriptive는 custom media type 이나 profile link relation 등으로 만족시킬 수 있다.
   • HATEOAS는 HTTP 헤더나 본문에 링크를 달아 만족시킬 수 있다.
6. REST를 따르지 않겠다면, “REST를 만족하지 않는 REST API”를 뭐라고 부를지 결정해야 할 것이다.
   • HTTP API라고 부를 수도 있고..
   • 그냥 REST API라고 부를 수도 있다.. (roy fielding 이 싫어함)

<관련 유튜브 영상! >

• 개발자라면 꼭 한번 봐야할 영상!! [DEVIEW]