- NAVER DEVIEW 2017 에서 공유되었던 내용입니다.
REpretational State Transfer
A way of providing interoperability between computer systems on the internet
WEB (1991) - 팀 버너스-리
Q : 어떻게 인터넷에서 정보를 공유할 것인가?
A : 정보들을 하이퍼 텍스트로 연결한다.
HTTP/1.0 (1994~1996)
로이 필딩 : “How do i improve HTTP without breaking the Web?”
→ HTTP Object Model
→ REST(1998) Microsoft 에서 발표
→ REST(2000) 로이 필딩의 박사 논문 (120 페이지, 지루하다)
API
XML-RPC (1998), by Microsoft → soap
Salesforce API(2000.2) : SOAP API 공개
Flickr API(2004.8) : SOAP API, REST API둘다 공개
REST 의 승리~~~ 와~~~
그런데...
CMIS (2008)
- CMS를 위한 표준
- EMS, IBM, MS 등이 함께 작업
- REST 바인딩 지원
로이 필딩 : “이건 REST 가 아니야!!!!!!”
Microsoft REST API Guidelines (2016)
- uri는 https://{serviceRoot}/{collection}/{id} 형식이어야한다.
- GET, PUT, DELETE, POST, HEAD, PATCH, OPTIONS를 지원해야한다.
- API 버저닝은 Major.minor로 하고 uri에 버전 정보를 포함시킨다.
- 등등...
로이 필딩 : “이건 REST 가 아니라고!!!!!!!!!!!!!”
로이 필딩
- “REST APIs must be hypertext-driven”
- “REST API를 위한 최고의 버저닝 전략은 버저닝을 안 하는 것”
REST API
- REST 아키텍쳐 스타일을 따르는 API
REST
- 분산 하이퍼미디어 시스템 (e.g. 웹)을 위한 아키텍쳐 스타일
아키텍쳐 스타일
- 제약조건의 집합
REST를 구성하는 제약조건/스타일
- client-server
- stateless
- cache
- uniform interface
- identification of resources
- manipulation of resourcces through representations
- self-descriptive messages
- hypermedia as the engine of application state (HATEOUS)
- layered system
- code-on-demand (optional)
- 서버에서 코드를 보내서 클라이언트에서 실행 할 수 있어야함 (자바스크립트)
Self-descriptive message
GET/ HTTP/1.1이 HTTP 요청 메시지는 뭔가 빠져있어서 self-descriptive 하지 못하다.
목적치를 추가하면 이제 self-descriptive
HATEOAS
애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다.
HATEOAS
왜 Uniform Interface??
독립적인 진화
- 서버와 클라이언트가 각각 독립적으로 진화한다.
- 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
- REST를 만들게 된 계기 - “How do I improve HTTP witout braking the WEB”
웹
- 웹 페이지를 변경했다고 웹 브라우저를 업데이트할 필요는 없다.
- 웹 브라우저를 업데이트했다고 웹 페이지를 변경할 필요도 없다.
- HTTP 명세가 변경되어도 웹은 잘 동작한다.
- HTML 명세가 변경되어도 웹은 잘 동작한다.
상호운용성(interoperability)에 대한 집착
- Referer 오타지만 안 고침
- charset 잘못 지은 이름이지만 안 고침
- HTTP 상태 코드 416
- HTTP/0.9 아직도 지원함 (크롬, 파이어폭스)
결국 REST는 목적을 달성하고 성공함
- HTTP 규약의 작성에 영향도 줌
근데 REST API는??
너무 어려워....
그냥 REST 하지 말까?
어떻게 할까?
- REST API를 구현하고 REST API라고 부른다
- REST API의 구현을 포기하고 HTTP API라고 부른다
- REST API가 아니지만 REST API라고 부른다.
API가 REST로 만들기 어려운 이유
HTML vs JSON
별도의 API 문서 필요
비교
HTML
JSON
