REST & REST API

REST

a way of providing interoperability between computer systems on the internet. 컴퓨터 시스템간의 상호운용성을 제공하는 방법중 하나

WEB (1991)

어떻게 인터넷에서 정보를 공유할 것인가? -> 정보들을 하이퍼텍스트로 연결한다. 형식 : HTML 식별자 : URI 전송 방법 : HTTP

HTTP/1.0 (1994-1996)

Roy T.Fielding : 어떻게 하면 웹을 망가뜨리지 않고 HTTP 프로토콜을 진보시킬 수 있을까? -> HTTP Object Model -> (1998) Representational State Transfer로 발표 -> (2000) “Architectural Styles and the Design of Network-based Software Architectures”로 발표

API

• XML-RPC(1998) 원격으로 다른 시스템의 메소드를 호출할 수 있는 프로토콜

• Salesforce API(SOAP)(2000.2)

• flickr API(2004.8)
  • SOAP, REST

• SOAP vs REST : REST가 단순하고 쉽다

• CMIS(2008) CMS를 위한 표준 REST 바인딩 지원 Roy T.Fielding “No REST in CMIS”

• REST API Guidelines(2016) uri는 https://{serviceRoot}/{collection}/{id} 형식이어야 한다. GET, PUT, DELETE, POST, HEAD, PATCH, OPTIONS를 지원해야 한다. 버저닝은 Major.minor로 하고 uri에 버전 정보를 포함시킨다. -> Roy T.Fielding “REST API가 아니라 HTTP API라고 해야 한다.” -> “REST APIs must be hypertext-driven” -> REST API를 위한 최고의 버저닝 전략은 버저닝을 안 하는 것

사람들이 생각하는 REST API와 Roy T.Fielding이 생각하는 REST API가 다르다. 문제가 뭘까?…

REST API

-> REST 아키텍쳐 스타일을 따르는 API

REST

-> 분산 하이퍼미디어 시스템(ex.웹)을 위한 아키텍쳐 스타일

아키텍쳐 스타일

-> 제약조건의 집합, 즉, 아키텍쳐 스타일을 모두 따라야 REST를 만족하는 것임

REST를 구성하는 스타일

• client-server
• stateless
• cache
• layered system
• uniform interface : 잘 만족 못함
  • uniform Interface의 제약조건
    1. 리소스가 uri로 식별되면 된다.
    2. 리소스를 만들거나 업데이트하거나 삭제할 때 http 메세지에 표현을 담아서 전송할 수 있어야 한다.
    3. self-descriptive messages(메세지는 스스로를 설명해야 한다.)
       • 메세지의 내용으로 온전히 해석이 가능해야 한다.
    4. hyper media as the engine of application state(HATEOAS)
       • 애플리케이션의 상태는 하이퍼링크를 이용해 전이되어야 한다.
         - 3,4번은 대부분 안 지켜짐
• code-on-demand(optional) : 서버에서 코드를 클라이언트를 보내서 실행할 수 있어야 한다(자바스크립트)

그렇다면 왜 Uniform Interface가 필요한가?

독립적 진화를 위해서…

• 서버와 클라이언트가 각각 독립적으로 진화한다.
• 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
• REST를 만들게 된 계기 : 어떻게 하면 웹을 망가뜨리지 않고 HTTP 프로토콜을 진보시킬 수 있을까?

웹은 잘 만족하나?

• REST를 아주 잘 만족하고 있음
• 웹 페이지를 변경했다고 브라우저를 업데이트할 필요X
• 반대도 성립
• HTTP 명세가 변경되거나 HTML 명세가 변경되도 웹은 잘 동작
• 어쨌든 최소한의 동작은 한다!!!!
  -> 웹은 어떻게 가능한걸까? HTML, HTTP, 웹 브라우저, 웹 서버 개발자들의 노력… 하위호환성을 깨면 안되기 때문에 어마어마한 시간이 들어감
  잘못 만들어진 구현체들과의 상호운용성조차도 지켜줘야 하기 때문에 다음과 같은 일이 존재한다.
  • Referer 오타지만 안 고침
  • charset 잘못 지은 이름이지만 안 고침
  • HTTP 상태 코드 416 포기함
  • HTTP/0.9 아직도 지원함(크롬, 파이어폭스)

REST가 웹의 독립적 진화에 도움을 주었나?

• HTTP 지속적으로 영향을 줌
• Host 헤더 추가
• 길이 제한을 다루는 방법이 명시(414 URI Too Long등)
• URL에서 리소스의 정의가 추상적으로 변경됨: “식별하고자 하는 무언가” 예전에는 “문서의 위치”로 정의했음
• 기타 HTTP와 URI에 많은 영향을 줌
• HTTP/1.1 명세 최신판에서 REST에 대한 언급이 들어감
• Roy T.Fielding가 REST 뿐 아니라 HTTP, URI 명세의 저자이기 때문

그럼 REST는 성공했는가?

• REST는 웹의 독립적 진화를 위해 만들어졌다.
• 웹은 독립적으로 진화하고 있다.

-> 성공

그렇다면 REST API는?

REST API는 제약조건을 다 지켜야 한다고 Roy T.Fielding가 명시함

현실적으로 쉽지 않은데 원격 API가 꼭 REST API여야 하는건가?

그건 아니라고 함!!

• 시스템 전체를 통제할 수 있다고 생각하거나, 진화에 관심이 없다면, REST에 대해 따지느라 시간을 낭비하지 마라

그럼 이제 어떻게 할까?

1. REST API를 구현하고 REST API라고 부른다.
2. REST API 구현을 포기하고 HTTP API라고 부른다. 3. REST API가 아니지만 REST API라고 부른다.(현재 상태)

1번 경우를 도전해보자

일단 왜 API는 REST가 잘 안되나 일반적인 웹과 비교 해본다.

“불완전” 하단 의미는 문법 해석은 가능하나, 의미를 해석하려면 별도로 문서(API 문서 등)가 필요하다는 의미

Self-descriptive

1. 응답 메시지의 Content-Type을 보고 media type이 text/html임을 확인
2. HTTP 명세에 media type은 IANA에 등록되어있다고 하므로, IANA에서 text/html의 설명을 찾는다.
3. IANA에 따르면 text/html의 명세는 http://www.w3.org/TR/html이므로 링크를 찾아가 명세를 해석한다.
4. 명세에 모든 태그의 해석방법이 나와있으므로 해석 가능

HATEOAS

a 태그를 이용해 표현된 링크를 통해 다음 상태로 전이될 수 있으므로 만족

Self-descriptive

1. 응답 메시지의 Content-Type을 보고 media type이 application/json임을 확인
2. HTTP 명세에 media type은 IANA에 등록되어있다고 하므로, IANA에서 application/json의 설명을 찾는다.
3. IANA에 따르면 application/json의 명세는 draft-ietf-jsonbis-rfc7159bis-04이므로 링크를 찾아가 명세를 해석한다.
4. 명세에 json 문서를 파싱하는 방법이 명시되어있으므로 성공적으로 파싱은 성공한다. **그러나 “id”가 무엇을 의미하고, “title”이 무엇을 의미하는지 알 방법은 없다. **

HATEOAS

링크가 없어 다음 상태로 전이할 수 없다.

HTML 성공, json 실패

그런데 Self-descriptive와 HATEOAS가 독립적 진화에 어떻게 도움이 되는가?

• Self-descriptive(확장 가능한 커뮤니케이션)
  • 서버나 클라이언트가 변경되더라도 오고가는 메시지는 언제나 메시지만으로 해석 가능하다.
• HATEOAS
  • 애플리케이션 상태 전이의 late binding : 어디서 어디로 전이가 가능한지 미리 결정되지 않는다. 어떤 상태로 전이가 완료되고 나서야 그 다음 전이될 수 있는 상태가 결정된다. 즉, 링크를 서버가 마음대로 바꿀 수 있다. 서버가 링크를 바꾸어도 클라이언트의 동작은 변하지 않는다.

---

정리

• 오늘날 대부분의 “REST API”는 사실 REST를 따르지 않고 있다.
• REST의 제약조건 중에서 Self-descriptive와 HATEOAS를 잘 만족하지 못한다.
• REST는 긴 시간에 걸쳐 진화하는 웹 애플리케이션을 위한 것이다.
• REST를 따를 것인지는 API를 설계하는 이들이 스스로 판단하여 결정해야 한다.
• 따를 것이라면, Self-descriptive와 HATEOAS를 만족시켜야 한다.
  • Self-descriptive는 custom media type이나 profile link relation 등으로 만족시킬 수 있다.
  • HATEOAS는 HTTP 헤더나 본문에 링크를 담아 만족시킬 수 있다.
  • 물론 단점들이 존재하지만…
• 따르지 않겠다면, 뭐라고 부를지 결정해야 한다.
  • HTTP API라고 부르거나 그냥 REST를 따르지 않음에도 REST API라고 부를 수도 있다.

---

References

• 참고