[들어가기전]
REST API라고하면, 데이터를 json으로 주고받고 행위에 맞게 HTTP Method를 셋팅해주는 것으로만 알고 있었다.(동영상 보기전까지)
몇 달전에 스프링을 이용한 RESTful 웹 서비스 구축하기 책을 보며 프로젝트를 따라해보았는데, 책의 마지막부분 쯤에 HATEOAS라는 부분이 있었다. spring에서 제공해주는 것인데 링크를 만들어주는 라이브러리 였다. REST API 구축하는데 이게 왜 들어가있지라는 궁금증을 갖긴 했었는데 이 동영상을 보고나니 그 궁금증이 풀렸다.
결론적으로 말하자면, 우리가 얇게 알고 만들었던 REST한 API는 사실 REST API가 아닐지도 모른다. 그저 HTTP API라고 불러야 하며 REST API는 여러가지 제약조건을 만족시켜야 한다.
REST
Representational State Transfer
a way of providing interoperability(상호 운용성) between computer systems on the Internet.
WEB(1991)의 등장
Q : 어떻게 인터넷에서 정보를 공유할 것인가?
A : 정보들을 하이퍼텍스트로 연결한다.
연결형식 : HTML, 식별자 : URI, 전송방법 HTTP
로이 필딩(Roy T.Fielding) - REST의 창시자
HTTP/1.0 (1994 - 1996)
로이필딩은 생각했다. "How do I improve HTTP without breaking the Web?"
그리고 로이필딩은 논문을 썼다. 그렇게 REST가 탄생했다. - REST(2000)
REST API - REST 아키텍처 스타일을 따르는 API
REST - 분산 하이퍼미디어 시스템(예 : 웹)을 위한 아키텍처 스타일
아키텍쳐 스타일
- 제역조건의 집합
- 제약조건을 모두 지켜야 REST를 따른다라고 말할 수 있음
REST를 구성하는 스타일
- client-server
- stateless
- cache
- uniform interface => 잘 만족을 못함
- layered system
- code-on-demand(optional) => Server에서 Code를 클라이언트로 보내서 실행할 수 있어야 한다.
우리가 생각하는 웹 애플리케이션에서는 기본적으로 위의 스타일을 만족하지만, uniform interface는 잘 만족하지 못한다.
Unifrom Interface의 제약조건
-
identification of resources
- resource가 uri로 식별되면 된다.
-
manipulation of resources through representations
- representation전송을 통해서 resource를 조작해야 한다. (GET, POST, UPDATE ...)
-
self-descriptive messages
-
메시지는 스스로를 설명해야 한다.
-
GET / HTTP/1.1
이 HTTP 요청 메시지는 뭔가 빠져있어서 self-descriptive하지 못하다. -
GET / HTTP/1.1
Host : www.example.org
목적지를 추가하면 이제 self-descriptive 하다라고 말할 수 있다. -
HTTP/1.1 200 OK
[ {"op" : "remove", "path" : "a/b/c/"} ]
self-descriptive하지 못하다. 어떻게 해석해야할지 모르기 때문이다. -
HTTP/1.1 200 OK
Content-Type : application/json[ {"op" : "remove", "path" : "a/b/c/"} ]
대괄호, 중괄호의 의미가 뭐인지 이해할 수 있기 때문에 파싱이가능해지고 문법을 해석할 수 있게 된다. 하지만 이것만으로는 부족한데 여기서 의미하는 "op"와 "path"의 의미를 모르기 때문이다. -
HTTP/1.1 200 OK
Content-Type : application/json-patch+json[ {"op" : "remove", "path" : "a/b/c/"} ]
json patch + json이라는 미디어 타입으로 정의되어 있는 메시지 이기 때문에 json patch라는 명세를 찾아가서 이것을 이해한다음에 메시지를 해석하면 올바르게 이 메시지의 의미를 해석할 수 있음 -
메시지 내용으로 온전히 해석이 가능해야한다.
-
-
hypermedia as the engine of application state(HATEOAS)
- HATEOAS : 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다.
- HATEOAS : 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다.
HTTP/1.1 200 OK
Content-Type : text/html
<html>
<head></head>
<body><a href="/test">test</a></body>
</html>html 같은 경우에는 HATEOAS를 만족함 a link로 연결되어 있기 때문이다.
HTTP/1.1 200 OK
Content-Type : application.json
Link : </articles/1>; rel="previous",
</articles/3>; rel="next";
{
"title" : "The second article",
"contents" : "blah blah ..."
}son으로도 만족시킬 수 있다. 링크라는 헤더가 이 리소스와 연결되어 있는 다른 리소스를 가리킬 수 있는 정보를 제공하는 헤더이다. 이전 게시물, 이후 게시물의 URI정보를 알려주고 있다.
Uniform Interface가 왜 필요한가?
- 독립적 진화
- 서버와 클라이언트가 각각 독립적으로 진화한다.
- 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
- REST를 만들게 된 계기 : "How do I imporve HTTP without breaking the Web"
REST API는 저 제약조건들을 다 지켜야 한다.
An API that provides network-based access to resources via a unifrom interface of self-descriptive messages containing hypertext to indicate potentail state transitions might be part of an overall system that is a RESTful application
하이퍼텍스트를 포함한 self-descriptive한 메시지의 uniform interface를 통해 리소스에 접근하는 API
Self-descriptive와 HATEOAS가 독립적 진화에 어떻게 도움이 되는걸까?
Self-descriptive
- 확장 가능한 커뮤니케이션
- 서버나 클라이언트가 변경되더라도 오고가는 메시지는 언제나 self-descriptive하므로 언제나 해석이 가능하다.
HATEOAS
- 애플리케이션 상태 전이의 late binding
- 어디서 어디로 전이가 가능한지 미리 결정되지 않는다. 어떤 상태로 전이가 완료되고 나서야 그 다음 전이될 수 있는 상태가 결정된다.
- 쉽게 말해서 : 링크는 동적으로 변경될 수 있다.
정리
- 오늘날 대부분의 "REST API"는 사실 REST를 따르지 않고 있다.
- REST의 제약조건 중에서 특히
Self-descriptive와HATEOAS를 잘 만족하지 못한다. - REST는 긴 시간에 걸쳐(수십년) 진화하는 웹 애플리케이션을 위한 것이다.
- REST를 따를 것인지는 API를 설계하는 이들이 스스로 판단하여 결정해야 한다.
- REST를 따르겠다면,
Self-descriptive와HATEOAS를 만족시켜야 한다.- Self-descriptive는 custom media type이나 profile link relation 등으로 만족시킬 수 있다.
- HATEOAS는 HTTP 헤더나 본문에 링크를 담아 만족시킬 수 있다.
'프로그래밍 노트 > WEB' 카테고리의 다른 글
| REST API 보안_1 (0) | 2019.05.30 |
|---|---|
| REST API 디자인 가이드 (0) | 2019.05.18 |
| HTTP란? (HTTP Message Format, Request Message & Response Message) (0) | 2019.05.13 |
| MIME 타입에 관하여 (0) | 2019.05.13 |
| URI란 무엇인가? (0) | 2019.05.03 |
