[Open API] REST Architecture 요약

REST Architecture

Oracle 에서 발표한 자료에서 설명한 내용을 정리한다.

Deview 2017 “그런 REST API로 괜찮은가”

Deview 2017 “그런 REST API로 괜찮은가” 발표자료

RESTFull API

RESEFull API는 기술적으로 다음 같이 발전해 왔다.

HTTP/1.0 1994-1996

Roy T. Fielding, HTTP Object Model

“How do i improve HTTP without breaking the Web?”

REST 1998

Roy T. Fielding, Microsoft Research 발표

“Representational State Transfer:
An Architectural Style for Distributed Hypermedia Interaction”

REST 2000

Roy T. Fielding, 박사 논문으로 발표

“Architectural Styles and the Design of Network-based Software Architectures”

이 기술의 근간은 Web API 이다.

SOAP

Micsoft에서도 XML-RPC 1998를 통해 Web API를 구현하고자 했다.

Microsoft, SOAP

Salesforce API

Salesforce API, 2000 은 이런 방식을 처음 도입했다.
https://web.archive.org/web/20001018092215/http://salesforce.com/

flickr API

flickr의 SOAP

https://web.archive.org/web/20040921173223/http://www.flickr.com:80/services/api/response.soap.html

flickr의 REST API

https://web.archive.org/web/20040821031039/http://www.flickr.com:80/services/api/response.rest.html

SOAP과 REST

SOAP	REST
- 복잡하다	- 단순하다
- 규칙 많음	- 규칙 적다
- 어렵다	- 쉽다

Google trends 검색

2006년, AWS가 자사 API의 85%를 REST로 구현
2010년, Salesforce.com에서 REST API 추가

CMIS

2008년 CMIS 표준 준비

• EMC, IBM, Microsoft등이 함께 작업
• REST 바인딩 지원

그러나 Roy T. Fielding: “No REST in CMIS”

REST API guideline

2016년 Microsft 가 제시한 REST API Guideline

Roy T. Fielding:
“s/REST API/HTTP API/“

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

그리고

“REST API를 위한 최고의 버저닝 전략은 버저닝을 안 하는 것”

결국 REST API는

• REST 아키텍쳐 스타일을 따르는 API
• 분산 하이퍼미디어 시스템(예: 웹)을 위한 아키텍쳐 스타일
• 아키텍쳐 스타일: 제약조건의 집합

REST 를 구성하는 스타일

아키텍쳐 스타일 은 다음 같이 구성된다:

• client-server
• stateless
• cache
• uniform interface
• layered system
• code-on-demand (optional)

Uniform interface

Uniform Interface는

• identification of resources
• manipulation of resources through representations
• self-descriptive messages
• hypermedia as the engine of application state (HATEOAS)

Self descriptive message

Self-descriptive message, 메시지는 스스로를 설명해야한다

GET / HTTP/1.1

이 HTTP 요청 메시지는 뭔가 빠져있어서 self-descriptive 하지 못하다.

목적지를 추가하면 이제 self-descriptive

GET / HTTP/1.1
Host: www.example.org

결과 메시지도

HTTP/1.1 200 OK

[ { "op": "remove", "path": "/a/b/c" } ]

HTTP/1.1 200 OK
Content-Type: application/json-patch+json

[ { "op": "remove", "path": "/a/b/c" } ]

HATEOAS

애플리케이션의 상태는 Hyperlink를 이용해 전이되어야한다.
http://slides.com/eungjun/rest#/37

독립성

서버와 클라이언트가 각각 독립적으로 진화한다.
서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
REST를 만들게 된 계기: “How do I improve HTTP without breaking the Web.”

호환성 유지

HTML5 첫 초안에서 권고안 나오는데까지 6년

• HTML5 드래프트 2008년 1월, 첫 권고안 2014년 10월

HTTP/1.1 명세 개정판 작업하는데 7년

• HTTP/1.1 명세 세 번째 개정판인 RFC 7230-7235의 작업기간 2007년 12월 - 2014년 6월

상호운용성에 대한 집착

Referer 오타지만 안 고침

Referer의 개념을 Tim Berners Lee에게 제안한 것은 Phillip M. Hallam-Baker 이지만, 이름까지 정해서 주지는 않았다고 한다. 따라서 오타를 만든 것은 Tim Berners Lee인 것으로 추정하는듯.

See https://lists.w3.org/Archives/Public/ietf-http-wg-old/1995JanApr/0109.htm

charset 잘못 지은 이름이지만 안 고침

charset은 “character set”이 아님에도 불구하고 그런 오해를 계속해서 불러일으키고 있다.

http://w3-org.9356.n7.nabble.com/How-to-pronounce-quot-charset-quot-td254585.html#message254629

HTTP 상태 코드 418 포기함 (I’m a teapot)

https://www.facebook.com/eungjun/posts/10213901564392694

HTTP/0.9 아직도 지원함 (크롬, 파이어폭스)

구글 크롬에서 HTTP/0.9 지원을 완전히 제거하려다 실패했다. Tenda D301 router와의 호환성이 깨지는 문제가 발견되어서. default port인 경우에만 HTTP/0.9를 지원하도록 하려고 했는데 그마저도 문제가 발견되어 revert했다:
https://bugs.chromium.org/p/chromium/issues/detail?id=624462

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 스타일 가이드를 따랴야 한다.링크

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

구현이 쉽지는 않다.

원격 API가 REST API여야 하나?

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

링크

REST emphasizes evolvability to sustain an uncontrollable system. If you think you have control over the system or aren’t interested in evolvability, don’t waste your time arguing about REST.
– Roy T. Fielding

현재는

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

그러므로 제약 조건을 따르던지 다른 단어를 써라!!!

I am getting frustrated by the number of people calling any HTTP-based interface a REST API. … Please try to adhere to them or choose some other buzzword for your API.
– Roy T. Fielding

일반 Web과 REST API 비교

http://slides.com/eungjun/rest#/63

open api spec

https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md