참조
https://www.youtube.com/watch?v=RP_f5dMoHFc
REST의 약자
REpresentational -> 표현
State -> 상태
Transfer -> 전송
자원(RESOURCE)의 표현에 의한 상태(정보) 전달
리소스를 URL에 표현하여 주고받을 정보에 대해 어느정도 예측할 수 있다.
REST
a way of providing interoperability between computer systems on the Internet
- 컴퓨터 시스템간에 상호운용성을 제공
- 분산 하이퍼미디어 시스템(예: 웹)을 위한 아키텍쳐 스타일
REST 탄생당시 경쟁자였던 SOAP
SOAP
REST
이러한 특성 차이로 인해서 REST가 살아남고 SOAP는 경쟁에서 밀려나게 되었다.
Microsoft REST API Guidelines (2016)
REST API란
- REST API란 REST 아키텍처 스타일을 따르는 API
- REST란 분산 하이퍼미디어 시스템(예: 웹)을 위한 아키텍쳐 스타일
- 아키텍처 스타일이란 제약조건의 집합
REST를 구성하는 아키텍처 스타일
- client-server
- stateless
- cache
- uniform interface
- layerd system
- code-on-demand (optional)
code-on-demand의 의미는 서버에서 코드를 클라이언트에 보내서 실행할 수 있어야 한다. ex) javascript
- identification of resources
- manipulation of resources through representations
- self-descriptive messages
- hypermedia as the engine of application state (HATEOAS)
HATEOAS : 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야한다.
for 독립적 진화
- 서버와 클라이언트가 각각 독립적으로 진화한다.
- 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
- REST를 만들게 된 계기
"How do I improve HTTP without breaking the web."
웹을 망가트리지 않고 HTTP를 발전시키는 방법
웹
- 웹 페이지를 변경했다고 웹 브라우저를 업데이트할 필요는 없다.
- 웹 브라우저를 업데이트했다고 웹 페이지를 변경할 필요도 없다.
- HTTP 명세가 변경되어도 웹은 잘 동작한다.
- HTML 명세가 변경되어도 웹은 잘 동작한다.
상호운용성(interoperabliity)에 대한 집착
- Referer 오타지만 안 고침 고치게되면 기존에 Referer를 사용하던 곳은 사용 불가하게 됨
- charset 잘못 지은 이름이지만 안 고침
- HTTP 상태 코드 416 포기함(I'm a teapot)
- HTTP/0.9 아직도 지원함 (크롬, 파이어폭스)
REST가 웹의 독립적 진화에 도움을 주었나
- HTTP에 지속적으로 영향을 줌
- HOST 헤더 추가
- 길이 제한을 다루는 방법이 명시 (414 URL Too Long 등)
- URL에서 리소스의 정의가 추상적으로 변경됨: "식별하고자 하는 무언가"
- 기타 HTTP와 URL에 많은 영향을 줌
- HTTP/1.1 명세 최신판에서 REST에 대한 언급이 들어감
REST API는 잘 지켜지고 있는가?
- REST API는 REST 아키텍쳐 스타일을 따라야한다.
- 오늘날 스스로 RESET API라고 하는 API들의 대부분이 REST 아키텍쳐 스타일을 따르지 않는다.
An API that provides network-based access to resources via a uniform interface of self-descriptive messages containing hypertext to indicate potential state transitions might be part of an overall system that is a RESTful application
-- Roy T. Fielding
하이퍼텍스트를 포함한 self-sescriptive한 메시지의 uniform interface를 통해 리소스에 접근하는 API
정리
-
오늘날 대부분의 "REST API"는 사실 REST를 따르지 않고 있다.
-
REST의 제약조건 중에서 특히 Self-descriptive와 HATEOAS를 잘 만족하지 못한다.
-
REST는 긴 시간에 걸쳐(수십년) 진화하는 웹 애플리케이션을 위한 것딩다.
-
REST를 따를 것인지는 API를 설계하는 이들이 스스로 판단하여 결정해야한다.
-
REST를 따르겠다면, self-descriptive와 HATEOAS를 만족시켜야한다.
- self-descriptive는 custom media type이나 profile link relation 등으로 만족시킬 수 있다.
- HATEOAS는 HTTP 헤더나 본문에 링크를 담아 만족시킬 수 있다.
-
REST를 따르지 않겠다면, "REST를 만족하지 않는 REST API"를 뭐라고 부를지 결정해야 할 것이다.
- HTTP API라고 부를 수도 있고
- 그냥 REST APIL라고도 부를 수 있다.