그런 REST API로 괜찮은가
REST API란?
- 분산 하이퍼미디어 시스템
먼저 WEB을 보자
-> 어떻게 인터넷에서 정보를 공유 할 것인가?
표현방식 : HTML 식별자: URL 전송방법: HTTP
그렇다면
How do i improve HTTP without breaking the Web??
- HTTP Object Web
이런 물음은 Roy T. Fielding박사 논문으로 발표 이때부터 REST API라 부름
Salesforce가 최초로 API를 공개 (2000년 2월)
-SOAP 조금 김
4년후에 Flickr API를 발표
-REST 짧음
SOAP은 복잡하고 규칙많고 어렵다.
REST는 단순하고 짧고 쉽다.
AWS는 REST API가 85%넘는다.
Salesforce도 REST API를 제공하기 시작함
이렇게 REST API의 세상이 펼쳐지기 시작하는것으로 보였으나
No REST in CMIS (2008년) 라고 REST API를 만든사람이 REST API가 아니라고 말한다.
MS의 REST API 가이드라인(2016)을 보고 REST API를 만든사람이 REST API가 아니라고 말한다.
REST를 구성하는 스타일
총 6가지의 스타일로 되어있다.
- client-server / stateless /cache / uniform interface / layered system / code-on-demand
uniform interface란?
- self-descriptive messages / hypermedia as the engine of application state(HATEOAS)
self-descriptive messages란?
- 목적지가 있어야한다.
HATEOAS란?
애플리케이션 상태의 전이가 있어야한다.
REST의 목적중의 하나인 독립적 진화
- 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
EX) 웹 - 웹페이지를 변경했다고 웹 브라우저를 업데이트할 필요는 없다.
- HTTP명세 HTML명세가 변경되어도 웹은 잘 동작된다.
HTML5첫 초안에서 권고안 나오는데까지 6년
HTTP/1.1명세 개정판 작업하는데 7년
이분들의 노력으로 웹은 위와 같은 현상을 유지한다.
상호운용성에 대한 집착
- Referer오타지만 안고침
- charset잘못지은이름이지만 안 고침
- HTTP 416 상태코드 포기함(I'm a teapot)
- HTTP/0.9 아직도 지원함
웹은 독립적진화를 위해서.. 엄청난 노력을 함 상호운용성에 목숨을 걸었구나 웹은 !!
그렇다면 실제로 REST가 웹의 독립적 진화에 도움을 주었나??
- HTTP에 지속적으로 영향을 줌
- Host 헤더 추가
- 길이 제한을 다루는 방법이 명시
- URI에서 리소스의 정의가 추상적으로 변경됨
- 기타 HTTP와 URI에 많은 영향을 줌
- HTTP/1.1 명세 최신판에서 REST에 대한 언급이 들어감
- Roy T.Fielding이 HTTP와 URI명세를 만든사람이다.
그렇다면 REST API는 어떠한가.?
- REST API도 REST의 모든 제약조건을 다 지켜야합니다.
만들기 어렵다.
꼭 REST를 따라야하나??
- Roy T.Fielding는 말했다. 시스템 전체를 통제할 수 있다고 생각하거나, 진화에 관심이 없다면, REST에 대해 따지느라 시간을 낭비하지 마라
그럼 이제 어떻게 할까?
1번. REST API를 구현한다.
2번. REST API구현을 포기하고 HTTP API라고 부른다.
3번. REST API가 아니지만 REST API라고 부른다.
현재 거의 모든 API는 3번이다.
Roy T.Fielding는 말합니다. 제발 제약 조건을 따르던지 아니면 다른 단어를 써라
data로 표현하거나 HTTP헤더를 이용하거나 기타 등등으로도 JSON API를 해결할 수 있다.
Media type를 꼭 등록해야하나?
- 요약 *
오늘날 대부분의 REST API는 사실 REST를 따르지 않고 있다.
REST의 제약조건 중에서 특히 self-descriptive와 HATEOAS를 잘 만족하지 못한다.
REST는 긴 시간에 걸쳐 진화하는 웹 애플리케이션을 위한 것이다.
self-descriptive와 HATEOAS를 만족시킬지 스스로 판단하여 결정해야한다.
HTTP API라고 부를 수도 있고 그냥 REST API라고 부를 수도 있다.