그런 REST API로 괜찮은가

섭·2022년 1월 6일

DEVIEW 2017의 그런 REST API로 괜찮은가를 보고 정리한 내용입니다

REST란?

Represetational State Transfer

Representational state transfer (REST) is a software architectural style that was created to guide the design and development of the architecture for the World Wide Web.

World Wide Web의 개발과 디자인을 위한 아키텍쳐 스타일
Representational state transfer

해당 영상에서는 분산 하이퍼미디어 시스템(Web)을 위한 아키텍쳐 스타일 이라고 말하며 이것만 보면 감이 전혀 잡히지 않는다
그래서 단순히 쓰여진 영어 단어만 보게되면 아래와 같다

Representational - 묘사한, 표현한, 나타낸
State - 상태
Transfer - 이전, 이동, 이송

따라서 위의 내용과 영어단어만을 보고 유추 해보자면 Web에서 data를 전송할 때 상태를 나타내는 방식? 이라고 일단 생각하고 다음으로 넘어가자
여기서 중요한건 data가 상태를 표현 한다는 것!

REST가 나온 배경

인터넷으로 어떻게 하면 정보를 잘 공유할 수 있을까? 의 대한 해답으로 WWW가 Tim Berners-Lee에 의해 탄생한다 (심지어 이사람은 물리학자)

WWW로 풀어낸 해결책은 정보들을 하이퍼텍스트로 연결한다!!

표현 형식: HTML
식별자 : URI
전송방법: HTTP

여기서 Roy T. Fielding 이라는 사람이 나오는데 이미 HTTP가 web의 전송 프로토콜로 이용되고 있는 시점에서 HTTP 1.0 설계에 참여하게 된다. (당시 대학원생)

"How do I improve HTTP without breaking the Web"

Roy가 해결책으로 제시한 것은 HTTP object model 이며 이것을 1998년도에 REST라는 이름으로 발표를 하게 되고 2년 후 2000년에
박사 논문(Architectural styles and the design of network-based software architectures)까지 발표한다.

API

Microsoft가 원격으로 다른 시스템의 메소드를 호출 할 수 있는 XML-RPC 라는 프로토콜을 만드는데(1998) 이게 나중에 SOAP 이라는 이름으로 바뀐다.
이 후 2000년도에 Salesforce 라는 회사에서 API를 공개하는 데 이러한 느낌이다.

이것만 딱 봐도 복잡해서 쓰기 힘들거 같다(와우 urn을 쓰네)

그런데 4년 후 2004년에 flickr(와 내가 쓰는 그 flickr인가 신기하다)에서 SOAP과 REST라는 이름으로 다양한 API를 발표한다

SOAP

REST

딱 봐도 SOAP에 비해서 훨신 간단해 보인다.
자연스럽게 SOAP의 사용량은 점점 줄어들고 REST의 사용량은 증가하게 된다.

Microsoft에서 2016년 REST API Guidelines을 만들었다.

URI는 https://{serviceRoot}/{collection}/{id} 형식이어야 한다
GET, PUT, DELETE, POST, HEAD, PATCH, OPTION 를 지원해야 한다
etc..

내용은 보통 우리가 생각하는 REST API의 구성으로 되어있으나 정작 REST를 정립한 Roy는 이것은 REST API가 아니니까 HTTP API라고 해야 된다고 했다.
사람들이 생각하는 REST와 Roy Fielding이 생각하는 REST가 다르다..!?

REST API

REST가 무엇인지는 위에서 대강 다루었다.
World Wide Web의 개발과 디자인을 위한 아키텍쳐 스타일 또는 분산 하이퍼미디어 시스템(Web)을 위한 아키텍쳐 스타일
그러면 아키텍쳐 스타일이란? 제약조건들의 집합이며 제약조건을 다 지켜야 한다
따라서 REST API란 REST의 제약조건을 모두 지키는 API를 일컫는다

REST 구성하는 스타일

client-server
stateless
cache
uniform interface
layered system
code-on-demand(optional): 서버에서 코드를 클라이언트로 보내서 실행 하는 것

HTTP만 따라도 언급된 제약조건의 대부분을 지킬 수 있는데 이 중에서 보통 uniform interface가 지켜지지 않아 Roy가 이를 REST라고 인정하지 않고 있다.

Uniform Interface

identification of resources 식별 가능한 자원
manipulation of resources through representations
self-descriptive message
HATEOAS

이 중에서 세번째, 네번째 제약조건들이 지켜지지 못하고있는 실정이다.

Identification of Resources

식별가능한 자원

GET /users/1 HTTP/1.1
Host: www.test.com

id가 1인 user를 불러온다는 것으로 식별이 가능하다

Manipulation of Resources Through Representations

묘사 또는 표현을 통한 자원의 조작

POST /users HTTP/1.1
Host: www.test.com
Content-Type: application/json

{
	"username" : "hello"
}

DELETE /users/1 HTTP/1.1
Host: www.test.com

POST 또는 DELETE로 자원의 조작을 표현하고 있다

self-descriptive message

메세지는 스스로를 설명해야 한다

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

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

json이라는 형태는 주어졌으나 그것만으로는 "op"가 의미하는 것, "path"가 의미하는 것을 알 수가 없기에 아래와 같은 형태를 취해야한다

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

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

현재 REST라고 일컬어 지는 API들은 media type을 단순히 json만을 명시하기 때문에 이것만 보고는 message를 해석 할 수 없으니 self-descriptive 하다고 할 수 없다.

HATEOAS - Hypermedia as the Engine of Application State

애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다.

메인페이지 -> 글 목록보기 -> 글 쓰기..... -> 목록 얻기
와 같은 일련의 과정들이 페이지에 있는 링크를 따라서 상태가 전이되었기 때문에 HATEOAS라고 말할 수 있다.

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

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

HTML같은 경우 a tag로 하이퍼링크가 나와있고 이를 통해서 다음상태로 전이가 가능하기 때문에 HATEOAS가 만족된다

HTTP/1.1 200 OK
Content-Type: application/json
Link: </articles/1>; rel="previous",
      </articles/3>; rel="next";

{
  "title" : "The second article",
  "contents": "This is the second articles... blah blah"
}

Link라는 header가 표준으로 문서가 나와있기 때문에 메세지를 이해할 수 있으며, 이 메세지를 통해서 이전 게시글 또는 다음 게시글의 링크로 상태전이가 가능하기에 json을 사용하더라도 HATEOAS가 만족된다. 단지 이렇게 사용되지 않을뿐

왜 Uniform Interface가 필요한가

독립적 진화

서버와 클라이언트가 각각 독립적으로 진화한다. 따라서 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
REST를 만든 계기가 "How do I improve HTTP without breaking the web" 이로부터 시작이 되었으며, 이 고민에 대해서 나온 결과가 REST이기 때문에 REST의 목적은 독립적인 진화이다.
독립적인 진화를 달성하기 위해서는 Uniform interface가 반듯이 만족이 되어야 한다

실제로 잘 지켜지고 있는가

REST를 잘 지키고 있는 사례는 web이다.

웹 페이지를 변경했다고 웹 브라우저를 업데이트 할 필요는 없다
웹 브라우저를 업데이트 했다고 웹 페이지를 변경할 필요도 없다
HTTP 명세가 변경되어도 웹은 잘 동작한다
HTML 명세가 변경되어도 웹은 잘 동작한다

웹은 독립적으로 진화하고 있기에 REST는 성공이라고 볼 수 있다.

REST API는 왜 잘 안되나?

REST가 성공적인 web과 비교하면 아래와 같다

	흔한 웹 페이지	HTTP API
Protocol	HTTP	HTTP
Communication	사람 - 기계	기계 - 기계
Media Type	HTML	JSON

웹 페이지는 사람이 보는 것이기에 communication방식이 프로그램간 이루어지는 API와 다를 수 밖에 없고 그러다 보니 media type도 서로 다르다.
따라서 media type이 REST API가 잘 안되는 원인이라고 유추할 수 있다

HTML과 JSON을 단순하게 비교하면 이렇다

	HTML	JSON
Hyperlink	됨 (a tag 등)	정의되어 있지 않음
Self-descriptive	됨 (HTML 명세)	불완전*

self-descriptive가 불완전하기 때문에 메세지의 해석을 위해서는 별도의 문서가 필요하다.

HTML

GET /todos HTTP/1.1
Host: example.org

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

<html>
  <body>
    <a href="https://todos/1">회사 가기</a>
    <a href="https://todos/2">집에 가기</a>
  </body>
</html>

self-descriptive 만족

응답 메세지의 Content-Type을 보고 media type이 text/html임을 확인
HTTP 명세에 media type은 IANA에 등록되어 있다고 하므로, IANA에서 test/html의 설명을 찾음
IANA 따르면 text/html의 명세는 http://www.w3.org/TR/html 이므로 링크를 찾아가 명세를 해석 (엄청 타고타고 간다..)
명세에 모든 태그의 해석방법이 구체적으로 나와있으므로 이 메세지를 온전히 해석할 수 있다

HATEOAS 만족

a tag를 이용해 표현된 링크를 통해 다음 상태로 전이 가능

JSON

GET /todos HTTP/1.1
Host: example.org

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

[
  {"id": 1, "title": "회사 가기"},
  {"id": 2, "title": "집에 가기"}
]

self-descriptive 충족 X

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

HATEOAS 충족 X

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

REST를 꼭 따라야 하나..?

If you think you have control over the system or aren't interested in evolvability, don't waste your time arguing about REST
시스템 전체를 통제할 수 있다고 생각하거나, 진화에 관심이 없다면, REST에 대해 따지느라 시간을 낭비하지 마라

라고 Roy Fielding이 말했으니 필수로 따를 필요는 없으나 REST를 따르지 않으면서 REST API라고 하면 Roy가 싫어한다

정리

오늘날 대부분의 REST API는 사실 REST를 따르지 않고 있다
REST의 제약조건 중에서 self-descriptive와 HATEOAS를 만족하지 못한다
REST는 긴 시간에 걸쳐 진화하는 웹 애플리케이션을 위한 것이다
REST를 따를 것인지는 API를 설계하는 이들이 스스로 판단하여 결정해야한다

REST, RESTful 에 대해서 막연하게 알고만 있던것을 이 영상을 보면서 알게 되었고, 엄밀하게는 많은 사람들이 제대로 잘 쓰지 못하는 것도 알게되었다.
영상을 그냥 보는 것보다 확실히 정리를 하게되면서 이것저것 더 찾아보기도 하고, 글로 옮기는 과정에서 보다 더 정제된 채로 습득이 되는 느낌이다.

그동안 보았던 영상들도 다시 한번 보면서 정리를 해봐야겠다.

확실히 인터넷에는 좋은 자료들이 많다. 과거에 힘들게 공부하던 이전 세대보다 확실히 좋은 환경인것만은 분명하다.

링크가 첨부된 영상을 꼭 보시길 권장합니다

섭

You only get one life. It's actually your duty to live it as fully as possible.

이전 포스트

Programmers - 가장 큰 수

다음 포스트

그런 REST API로 괜찮은가

REST란?

Represetational State Transfer

REST가 나온 배경

API

REST API

REST 구성하는 스타일

Uniform Interface

Identification of Resources

Manipulation of Resources Through Representations

self-descriptive message

HATEOAS - Hypermedia as the Engine of Application State

왜 Uniform Interface가 필요한가

독립적 진화

실제로 잘 지켜지고 있는가

REST API는 왜 잘 안되나?

HTML

JSON

REST를 꼭 따라야 하나..?

정리

Programmers - 가장 큰 수

그런 REST API로 괜찮은가

0개의 댓글