REST는 REpresentation State Transfer, application 사이의 결합도를 낮추기 위한 아키텍쳐 스타일이다. 아키텍쳐 스타일이라는 말은 제약조건의 집합이라는 뜻. REST는 아키텍쳐 스타일인 동시에 아키텍쳐 스타일의 집합이다.
REST는 URI와 HTTP method 로 무엇을 어떻게 할지가 잘 정의된 API라고 할 수 있다.
REST를 구성하는 architecture style
client-server
네트워크가 클라이언트와 서버로 구성되어야 함을 의미한다. 서버는 리소스를 보여주고, 클라이언트는 서버에 저장된 리소스와 상호작용한다. 일대일 통신을 기반으로 한다.
stateless
http와 같이 client의 이전 상태(작업)를 기록하지 않는 접속을 뜻한다. 반대로 stateful은 이전 상태를 기록해 두었다가 정보로 활용하는 것.
uniform interface
"How do I improve HTTP without breaking the Web"
서버와 클라이언트 사이에 공통 언어가 있어서 시스템을 망가뜨리지 않고 정보를 교환하거나 수정할 수 있음을 의미한다. uniform interface가 적용된 웹은 서버가 변경되어도 클라이언트를 업데이트 할 필요가 없게 한다.
identification of resource, manipulation of resource throgh representations, self-descriptive message, hypermedia 의 4가지 하위조건을 통해 달성될 수 있다.
identification of resource
리소스가 안정적인 uri로 식별되어야 한다. 안정적인 uri라는 말은, 서버와 클라이언트의 상호작용으로 인해 변경되지않으며, 리소스상태가 변경되더라도 변경되지 않는다는 뜻.
manipulation of resource throgh representations
클라이언트가 서버에 표현을 보내서 리소스를 조작할 수 있다. 추가, 삭제, 수정하려는 컨텐츠가 포함된 json 객체를 보내고, 서버는 리소스를 제어한다.(그렇지만 조작이 강제되는 것은 아니다. 서버가 제어에 대한 권한을 갖는다.)
self-descriptive message
메시지가 스스로를 설명해야 한다. 다시말해, 수신자가 이해하는데에 필요한 모든 정보를 메시지에 포함해야 한다.
다음은 self-descriptige message를 만족하는 메시지의 예시이다.
GET / HTTP/1.1
Host: www.example.com이 요청 메시지는 http method, 사용된 프로토콜(HTTP 1.1)과 목적지(host)를 명시해 self-descriptige message를 만족한다.
HTTP/1.1 200 OK
Content-Type: application/json-patch+json
[{ "key" : "abc" }]이 응답 메시지는 사용된 프로토콜과 컨텐츠타입 헤더를 명시하여 컨텐츠를 이해할 수 있는 방법을 제시한다. self-descriptige message를 만족한다.
HTTP/1.1 200 OK
Content-Type: text/html
<!DOCTYPE html>
<html>
<head>
<title>Home Page</title>
</head>
</body>
<div>Hello World!</div>
<a href= “http://www.recurse.com”> Check out the Recurse Center! </a>
<img src="awesome-pic.jpg">
</body>
</html>마찬가지.
Hypermedia as the engine of application state (HATEOAS)
애플리케이션의 상태가 Hypermedia를 통해 전이되어야 한다는 의미이다. 하이퍼 미디어는 서버에서 클라이언트로 전송되는 데이터를 나타내는 단어이다. 다시 말해 클라이언트가 다음에 수행할 수 있는 작업에 대한 정보를 서버가 먼저 보내줘야 한다는 말이다.
HTML 사용시에는
<a href="http://www.recurse.com">Check out the Recurse Center!</a>
라면 사용자가 링크 클릭시에 http://www.recurse.com 로 GET 요청을 해야 한다고 클라이언트에 알려주는 것.
JSON 사용시에는
HTTP/1.1 200 OK
Content-Type: application/json
Link: </articles/1>; rel="previous",
</articles/3>; rel="nest";
{
"title": "The second article",
"contents": "blah blah..."
}
link 라는 헤더를 통해 다음 목적지를 명시한다.
정확히는 해당 화면에서 보여주어야 하는 링크들의 레퍼런스를 미리 제공한다. 라고 생각하는 것이 좋을 듯 하다.
cache
서버응답시에 응답을 cache화 시켜도 되는지, 그리고 어떻게, 얼마나 오래 cache화 시켜도 되는지를 명시해야 한다는 것을 의미한다.
요청별 cache 가능 여부
- GET - 기본적으로는 특별한 조건이 발생할때까지 cache로 저장해도 된다.
- POST - 기본적으로는 cache화가 불가능하지만,
Expires헤더나Cache-Control헤더로 cache 가능함을 명시할 수 있다. - PUT, DELETE - cache가 불가능하도록 디자인하는 것이 적합하다.
Cache 헤더
-
Expire - 만료 시간을 절대시간으로 표시하여 지정한다.
Expires: Fri, 20 May 2016 19:20:49 KST -
Cache-Control -
max-age,max-style,min-fresh등으로 구성된 cache direction을 통해 제시한다.
R.Fielding : Hypertext Transfer Protocol (HTTP/1.1): Caching 에서 자세한 cache header와 direction을 확인할 수 있다
layered system
서버와 클라이언트보다 더 많은 구성요소를 사용할 수 있음을 뜻한다. 예를 들어 프록시 서버.
code-on-demand(optional)
서버에서 코드를 클라이언트로 보내서 실행할 수 있어야 한다.
REFERENCE
R.Fielding : Hypertext Transfer Protocol (HTTP/1.1): Caching
Lauren Long - RESTful이 실제로 의미하는 것
'knowledge > development' 카테고리의 다른 글
| 프로그래밍 패러다임(1) - 프로그래밍 패러다임과 언어의 관계 (0) | 2020.08.05 |
|---|---|
| final과 static (0) | 2020.07.15 |
| Dependency Injection (0) | 2020.06.08 |
| 대체 etc/hosts는 뭐하는 친구인가 (0) | 2020.06.08 |
