REST API

공부정리

REST API

에드박 2020. 8. 13. 01:58

누군가 "REST API를 설명하시오." 라고하면 "REST 하게 만드는 API 입니다." 하고 끝납니다.

제가 지향하는 "이해했다" 라는 것은 프로그래밍에 대한 지식이 없는 사람에게 설명해서 이해시킬 수 있는 것입니다.

지금은 정확하게 이거다! 라고 설명하기가 어렵습니다.

1. REST (Representational State Transfer)

Roy T. Fielding 이란 사람이 HTTP 1.0 프로토콜 작업에 참여했는데 HTTP를 정립하고, 명세에 기능을 더하고 기존의

기능을 고쳐야하는 상황에 처했습니다. 이 때 Roy T. Fielding은 기능을 더하거나 고칠 때 기존에 구축되어 있는 웹과의 호환성에 문제가 생기는걸 피하기 어렵겠다 라고 생각합니다. 그래서 어떻게 하면 웹과의 호환성을 유지하면서

HTTP를 진보시킬 수 있을까 라고 고민하여 나온것이 HTTP Object Model 입니다.

HTTP Object Model 은 나중에 Roy T. Fielding 이 1998년 Microsoft Research에 가서 REST 라는 이름으로 발표합니다.

2000년 Roy T. Fielding이 REST를 박사 논문으로 발표합니다.

HTTP : 웹 문서 전송 프로토콜 입니다. 하나의 체계 같은 것이며 지금 보고있는 웹페이지도 HTTP 를 사용해서 전송되어진 것입니다.

Roy T. Fieding은 REST API에 엄격합니다. EMC, IBM, Microsoft 등이 함께 작업한 CMIS(CMS를 위한 표준)은 'REST바인딩을 지원한다' 라고 CMIS를 제작한 사람들이 발표했지만 Roy T. Fielding은 이런말을 합니다. "CMIS에 REST는 없다."
Microsoft 에서 발표한 REST API Guidelines 의 내용은 다음과 같습니다.
- uri 는 https://{serviceRoot}/{collection}/{id} 형식이어야 한다.
- GET, PUT, DELETE, POST, HEAD, PATCH, OPTIONS 를 지원해야한다.
- API 버저닝은 Major.minor로 하고 uri에 버전정보를 포함시킨다.
- 등등..
하지만 Roy T. Fielding 은 "이건 REST API가 아니다 HTTP API다" 라고 합니다.

그렇다면 REST 한 API 란 무엇일까요?

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

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

아키텍쳐 스타일 : 제약조건의 집합

REST를 구성하는 스타일

Client-Server : REST서버는 API 제공 / 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보) 등을 직접 관리하는 구조로 서버와 클라이언트의 기능이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야할 내용이 명확해지고 서로간의 의존성이 줄어듭니다.
Stateless : 무상태성. 작업을 위한 상태정보를 저장하거나 관리하지 않습니다. API 서버는 단순히 들어오는 요청만 처리하면 됩니다. 때문에 서비스의 자유도가 높아지고 불필요한 정보를 저장하지 않아서 구현이 단순해집니다.
Cache : 캐시 처리기능, HTTP 가 가진 캐싱 기능을 사용할 수 있습니다. HTTP 프로토콜에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능합니다.
Uniform Interface : 중요!
Layered System : Rest 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상에 유연성을 둘 수 있고 Proxy, Gateway 와 같은 네트워크 기반의 중간 매체를 사용할 수 있습니다.
Code-on-demand(optional) : Server 측에서 코드를 Client 에게 전송해 실행할 수 있어야한다.( Java Script )

Uniform Interface의 4가지 제약조건

identification of resources - 리소스가 uri로 식별되면 된다.
manipulation of resources through representations - representation 전송을 통해 리소스를 조작해야한다.
self-descriptive message - 메시지가 스스로 설명해야한다.
hypermedia as the engine of application state (HATEOAS)

self-descriptive message - 메시지가 스스로를 설명해야 합니다.

GET / HTTP / 1.1

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

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

- 목적지(HOST)를 추가하면 self-descriptive

HTTP / 1.1 200 OK
Content-Type : application/json
[{"op" : "remove", "path" : "/a/b/c" }

- 클라이언트가 응답을 받고 해석해야 하는데 Content-Type 이 생략되면 어떤 문법으로 작성된건지 모릅니다.

- 아직 "op, path 값이 무엇이지? 설명이 없는데" 할 수 있습니다. 이것의 설명이 필요합니다.

- 설명은 Content-Type : application/json-patch+json 이라고 해야 완전해집니다. json-patch+json 이라는 명세를 찾아가서 이 메시지의 내용을 확인해야 합니다.

HATEOAS - 애플리케이션의 상태는 Hyper link 를 이용해 전이되야 합니다.

즉 링크를 따라가며 애플리케이션 상태를 전이합니다. 아래와 같은 형태입니다.

HTTP/1.1 200 OK
Content-Type : text/html

<html>
<head></head>
<body>
	<a href='/test'>test</a>
</body>
</html>

a태그로 페이지를 이동할 수 있기 때문에 HATEOAS 를 만족합니다.

HTTP/1.1 200 OK
Content-Type : application/json
Link : </articles/1>; rel="previous",
       </articles/3>; rel="next"
{
	"title" : "The second article",
    "content" : "blah blah blah"
}

Link 는 하이퍼링크로 다른 리소스로 넘어갈 수 있는 헤더입니다. 따라서 전이가 가능하여 HATEOAS 를 만족합니다.

헤더 라는 것은 HTTP 통신에서 특정 동작에 관한 이름입니다.
자세한것은 HTTP 통신을 공부하시면 됩니다. 다음 책은 HTTP 통신을 처음 접할 때 좋은 책입니다.
http://www.yes24.com/Product/Goods/15894097

왜 Uniform Interface 가 필요한가?

-> 독립적인 진화를 하기 위해서

서버와 클라이언트가 각각 독립적으로 진화합니다.
서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없습니다.
REST를 만들게 된 계기 "어떻게 하면 HTTP/1.0을 만들 때 웹이 깨지지 않고 진보할 수 있을까?"

웹은 REST 가 잘 적용되어 있습니다.(Chrome, IE, FireFox 등등)

웹 페이지가 변경 되었다고 웹 브라우저를 업데이트 하는 일은 없습니다.
웹 브라우저 업데이트시 웹 페이지를 변경할 필요가 없습니다.
HTTP 명세를 변경하더라도 웹은 잘 동작합니다.
HTML 명세를 변경하더라도 웹은 잘 동작합니다.

REST가 웹의 독립적 진화에 준 도움

HTTP에 지속적으로 영향을 줌
Host 헤더 추가
길이 제한을 다루는 방법을 명시 (414 URI Too Long)
URI에서 리소스의 정의가 추상적으로 변경됨 : "식별하고자 하는 무언가" (예전에는 문서의 위치 로 정의했습니다)
기타 HTTP 와 URI에 많은 영향을 줬습니다.
HTTP/1.1 최근 명세판에 REST에 대한 언급이 들어갔습니다.