REST란?

많이 듣고 많이 사용하는 개념이지만 알 것 같으면서도 모르겠는 REST에 대해 찾아 보던 중 정말 잘 설명한 영상이 있어 정리를 했습니다

REST란 REpresentational State Transfer의 약자인데 해석해 보면 대표적인 상태 전송 방법인데... 약자를 보아도 무슨 의미인지 유추하기가 매우 힘듭니다

rest wiki에서의 설명

위키백과에서도 컴퓨터 간에 상호 운용성을 제공하는 것중에 하나라는 설명이 있지만 아직 이해하기에는 부족합니다

그래서 접근 방법을 바꾸어 REST가 어디서 부터 나왔는지 알아보도록 하겠습니다.

REST의 시작

WEB(1991)

Q : 어떻게 인터넷에서 정보를 공유할 것인가?

A : 정보들을 하이퍼텍스트로 연결한다.

표현 형식 : HTML

식별자 : URI

전송 방법 : HTTP

HTTP/1.0 (1994-1996)

HTTP 1.0명세가 나오기 전에 이미 전송 프로토콜로 이용이 되고 있었고 전세계에는 수많은 웹이 존재하고 있었다,

이 시점에서 Roy T.fielding은 HTTP를 정립하고 명세에 기능을 더하고 기존에 기능을 고쳐햐하는 상황에 있었고 어떻게 하면 기존의 web을 깨지 않고 할 수 있을지 고민을 했다.

여기서 나온 해결책이 HTTP object Model 이고 이는 4년 후에 REST라고 이름으로 발표를 한다.

REST(1998)

Microsoft Research에서 Roy T.fielding이 발표

2년 후 Roy T.fielding은 박사 논문을 발표했고 오늘날의 REST를 정의한 문서이다

---

REST vs SOAP

XML-RPC(1998)

마이크로 소프트에서 발표한 원격으로 다른 시스템의 메소드를 호출 할 수 있는 프로토콜이며 추후 SOAP이라고 불린다

Salesforce API(2000.2)

Salesforce 회사에서 API를 공개 했고 인터넷에서 거의 최초로 공개된 API라고 볼 수 있다

어떤 id로 오브젝트 하나를 가져오는 API

하지만 사진에서 보듯 너무 복잡해서 잘 사용하지는 않았다.

flickr API(2004.8)

4년 후 flickr에서 SOAP과 REST API를 발표했다.

SOAP

REST

이걸 본 사람들은 REST가 훨씬 짧기 때문에 SOAP에 비해 단순하고 쉽다고 생각을 하게 되었고 REST는 점점 많이 사용하게 되었다

Microsoft REST API Guidelines(2016)

 - uri는 https://{serviceRoot}/{collection}/{id} 형식이어야 한다

 - GET, PUT, DELETE, POST, HEAD, PATCH, OPTIONS를 지원해야 한다

 - API 버저닝은 Major.minor로 하고 uri에 버전 정보를 포함시킨다

 - 등등

이라고 발표를 했고 사람들이 보기에 알고있던 REST를 정리한 것이라고 생각했는데 Roy T.Fielding은 이를 보고 REST API가 아닌 HTTP API라고 하는 것이 맞다고 말을 하게 된다.

그리고 블로그에 "REST APIs must be hypertext-driven"이고 적는다

해석해 보자면 "API가 hypertext 주도로 동작하지 않는다면, REST API가 아니다."

사람들이 알고 있던 REST의 개념과 Roy T.Fielding이 말하는 REST의 개념이 너무 달랐다.

---

다시 본론으로

그럼 REST API는 무엇인가?

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

REST는 무엇인가?

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

아키텍쳐 스타일이란?

제약 조건의 집합

그러므로 제약 조건들을 모두 따라야 REST 라고 할 수 있다.

다시 정리하면 REST는 아키텍쳐 스타일임과 동시에 아키텍쳐 스타일들의 모음이며 아래의 6가지의 규칙이 있다.

대체로 오늘날의 REST API는 잘 지켜지는데 그 이유는 HTTP만 잘 따라도 uniform interface를 제외한 조건들은 충족이 되기 때문이다.

code-on-demand란 서버에서 코드를 클라이언트로 보내서 실행할 수 있어야 한다는 뜻이고 자바스크립트를 이야기 한다고 보면 된다.

---

unoform interface란?

 - 리소스가 URI로 식별되면 된다

 - 리소스를 삭제, 수정, 삽입 등을 할 때 HTTP 메세지에 표현을 담아서 전송해야 한다.

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

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

위의 두가지는 대체적으로 잘 지켜지지만 밑의 두가지는 지켜지지 않고 있는데 어떤 조건인지 한번 알아보자.

self-descriptive messages

목적지가 빠져있어 self-descriptive 하지 못하다

목적지를 추가해야 self-descriptive

Content - Type 헤더가 들어가 있어야 한다. json이라는 형식이며, patch+json이라는 미디어 타입의 명세로 되어 있다고 알려주어야 한다.

self-descriptive messages는 안에 있는 메세지를 통해 해당 내용을 온전히 해석이 가능해야 한다

대부분 미디어 타입에 대한 내용이 빠져있고 json형식이라는 것만 적혀 있어 REST라고 하기 힘들다

HATEOAS

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

json의 경우 Link 헤더에 명시함으로서 Hyperlink를 통해 전이가 가능해 진다

왜 Unoform Interface가 필요한가?

독립적 진화를 위해

- 서버와 클라이언트가 각각 독립적으로 진화한다

- 서버의 기능이 변경되어도 클라이언트를 업데이트 할 필요가 없다

- REST를 만들게 된 계기 : 이전에 웹을 어떻게 하면 깨지 않고 HTTP를 명세할 것인가

웹

- 웹 페이지를 변경했다고 웹 브라우저를 웹데이트 할 필요는 없다

- 웹 브라우저를 업데이트 했다고 웹 페이지를 변경할 필요도 없다

- HTTP 명세가 변경되어도 잘 동작한다.

- HTML 명세가 변경되어도 잘 동작한다

모바일의 경우 서버가 변경되었을 때 업데이트가 필요한 경우가 많다

즉, 모바일은 REST 아키텍쳐를 따르고 있지 않다

웹에서 이런 것이 가능한 이유는 많은 사람들의 노력 때문이다

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

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

 - 그만큼 상호운용성에 대해 굉장한 집착이 있다

---

REST가 웹의 독립적 진화에 도움을 주었나

- HTTP에 지속적으로 영향을 줌

- Host 헤더 추가

- 길이 제한을 다루는 방법이 명시

- URI에서 리소스의 정의가 추상적으로 변경됨: "식별하고자 하는 무언가"

- 기타 HTTP와 URI에 많은 영향을 줌

- HTTP/1.1 명세 최신판에서 REST에 대한 언급이 들어감

- remind : Roy T.Fielding이 HTTP와 URI 명세의 저자 중 한명이다

REST는 웹의 독립적인 진화를 위해 만들어 졌고 웹은 현재 독립적으로 진화 하고 있다.

다음 글은 REST API에 관해 정리 하겠습니다

REST API란?

출처 : 그런 REST API로 괜찮은가