Microsoft REST API Guidelines(2016)
Microsoft에서 2016년에 REST API Guidelines를 발표.
URI는 https://{serviceRoot}/{CCollection}/{id} 형식이어야 함.
GET, PUT, DELETE, POST, HEAD, PATCH, OPTIONS를 지원해야 함.
API 버저닝은 Major, minor로 하고 URI에 버전 정보를 포함시킴.
하지만 Roy Fielding는 "이건 REST API가 아니다. HTTP API다."라고 말을 했습니다..
그럼 뭐가 문제일까요?
REST API란 REST 아키텍처를 준수해야 합니다.
REST는 분산 하이퍼미디어 시스템을 위한 아키텍처 스타일입니다.
아키텍처 스타일이란 제약조건의 집합입니다.
REST를 구성하는 스타일은 뭐가 있을까요?
client-server
-아키텍처를 단순화시키고 작은 단위로 분리(decouple)함으로써 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있도록 해줍니다.
stateless
-클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존하지 않음을 의미한다. HTTP는 stateless를 기본적으로 가지고 있다.
cache
-WWW에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 합니다.
layered system
-클라이언트는 대상 서버에 직접 연결되었는지, 또는 미들웨어에 연결되었는지를 알 수 없어야 합니다.
code-on-demand(optional)
-서버로부터 코드를 받아 실행할 수 있는 것입니다. (자바스크립트)
위의 REST 스타일들은 잘 지켜지는데, 그렇지 않은 스타일이 1가지 있습니다.
uniform interface입니다.
uniform interface란?
identification of resources
-리소스가 uri로 식별되어야 한다.
manipulation of resources through representations
-리소스를 만들거나 업데이트나 삭제할 때 HTTP 메시지에 표현을 담아 전송해서 달성한다.
self-descriptive message
-메시지는 스스로 설명해야 한다.
HATEOAS
-애플리케이션 상태의 전이입니다.
uniform interface 중 self-descriptivemessage와 HATEOAS가 잘 지켜지지 않습니다.
self-descriptive message란?
요청
요청을 보낼 때 이런 형식으로만 보내면 안 됩니다.
목적지가 있어야 self-descriptive입니다.
응답
위의 내용은 Content-Type이 application/json이라는 것 까지는 알 수 있지만, 응답 내용으로 받은 op와 path가 어떤 데이터인지 알 수 없습니다.
위의 내용처럼 application/hson-patch+json 까지 받아야 json patch의 명세를 찾아가서 이해 후 메시지를 올바르게 해석 가능합니다.
오늘날은 application/json 까지만 정의되어 있는 경우가 대다수입니다.
REST하지 못하다고 할 수 있습니다.
HATEOAS란?
HTML A태그를 통해 하이퍼링크가 나와있고 하이퍼링크를 통해서 다음 상태로 전이 가능해야 합니다.
WHY?
독립적 진화를 위해.
서버와 클라이언트가 각각 독립적으로 진화해야 함.
서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없음.
HTTP를 고치면 웹이 깨질 것 같은데 어떻게 할지 고민 끝에 나온 것이 REST.
REST는 독립적인 진화가 목적.
독립적인 진화란?
uniform interface를 반드시 만족.
uniform interface를 만족하지 못하면 REST가 아님.
REST가 웹의 독립적 진화에 도움을 주었나?
HTTP에 지속적으로 영향을 줌.
HOST 헤더 추가.
길이 제한을 다루는 방법 명시(414 URI Too Long 등)
URI에서 리소스의 정의가 추상 적로 변경됨(식별하고자 하는 무언가)
기타 HTTP와 URI에 많은 영향을 줌.
HTTP/1.1 명세 최신판에서 REST에 대한 언급이 들어감.
Reminder: Roy T. Fielding이 HTTP와 URI명세의 저자 중 한 명.
그럼 REST는 성공했는가?
REST는 웹의 독립적 진화를 위해 만들어졌음.
웹은 독립적으로 진화하고 있음.
성공이라고 봄.
REST API는?
REST API는 REST 아키텍처 스타일을 따라야 합니다.
오늘날 스스로 REST API라고 하는 API들은 대부분이 REST 아키텍처 스타일을 따르지 않습니다.
REST API 제약조건을 모두 지켜야 하는가?
Roy Fielding가 "하이퍼텍스트를 포함한 self-descriptive 한 메시지의 uniform interface를 통해 리소스에 접근하는 API"라고 선언했습니다.
REST API 제약조건을 지키지 않는다면 REST API가 아닙니다.
API는 꼭 REST API여야 하는가?
Roy T.Fielding는 "시스템 전체를 통제할 수 있다고 생각하거나, 진화에 관심이 없다면, REST에 대해 따지느라 시간을 낭비하지 마라."라고 말을 했습니다.
현재
REST API를 구현하고 REST API라고 부른다.
REST API 구현을 포기하고 HTTP API라고 부른다.
REST API가 아니지만 REST API라고 부른다.(현재 상태)
Roy T.Fielding은 "제발 제약 조건을 따르던지 아니면 다른 단어를 써라."라는 말을 했습니다.
후기
현재 사용하고 있는 API가 REST API인지 다시 생각해봐야 합니다.
참조 자료: 유튜브 그런 REST API로 괜찮은가?