그런 REST API로 괜찮은가

1. Rest

2. CMS(2008)

3. WEB

4. REST가 웹의 독립적 진화에 도움을 주었는가

5. 그렇다면 REST API는?

6. REST API를 구현하고 REST API라고 부른다면?

7. REST의 최종정리

1. Rest

1-1) Web(1991)

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

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

→ 표현 방식 : HTML(HTML로 정보들을 표현)

→ 식별자 : URL(그 정보들의 식별자로 URL을 만듦)

→ 전송방법 : HTTP(HTTP라는 프로토콜로 전송방법을 해결함.)

1-2) HTTP/1.0(1994-1996)

Q : 어떻게하면 Web을 망가뜨리지 않고 HTTP를 한 단계 발전시킬 수 있을까?

해결책 : HTTP Object Model

→ 4년 뒤에 HTTP Object Model이 Rest(1998)로 발표 함.

→ 2년 뒤 Roy T. Fielding(로이 필딩)은 박사 논문으로 발표함.

⇒ 그의 논문이 오늘날 Rest의 정의가 됨.

1-3) API(Click)

1-3)-1. XML-RPC(1998) by Microsoft → SOAP(나중에 이 이름으로 바뀜)

→ 프로토콜의 일종으로서, 인코딩 형식에서는 XML을 채택.

→ 전송 방식에서는 HTTP 프로토콜을 사용하고 있다.

→ XML-RPC는 매우 단순한 규약으로서, 작은 데이터 형식이나 명령을 정의하는 정도로만 사용.

1-3)-2. Salesforce API(2000.2)

→ 인터넷에서 거의 최초로 공개된 API임.

SOAP을 이용한 Salesforce API Structure(Click)

→ 어떤 ID로 Object 하나를 가져오는 API의 요청 메시지가 이정도 분량임.

→ 굉장히 복잡함.

⇒ Salsesforce API는 복잡해서 인기가 없었음.

1-4)-3. Flickr API(2004.8)

→ SOAP과 REST라는 형태 두 가지로 API를 만들어 냈음.

Untitled

1-5) Rest vs SOAP

Untitled

→ 2006년, AWS가 자사 API의 사용량의 85%가 Rest임을 밝힘.

→ 2010년, Salesforec.com, Rest API를 지원하게 됨.

2. CMS(2008)

2-1) CMS

CMS(저작물 관리 시스템)를 위한 표준. EMC, IBM, Microsoft 등이 함께 작업

REST 바인딩 지원(데이터는 SOAP 형식이 아닌 텍스트 기반 형식으로 웹에서 전송 됨.)

2-2) Microsoft REST API Guidelines(2016)

URI는 https://{serviceRoot}/{collection}/{id} 형식이어야 함.

GET, PUT, DELETE, POST, HEAD, PATCH, OPTIONS를 지원해야 함.

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

→ 사람들이 보기에 합리적이라고 생각했음.

⇒ 하지만 REST를 만든 로이 필 딩이 말하는 건

⇒ "REST API를 위한 최고의 버저닝 전략은 버저닝을 안 하는 것."

2-3) 뭐가 문제인 걸까?

2-3)-1. REST API

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

2-3)-2. REST

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

2-3)-3. 아키택처 스타일

제약 조건의 집합

→ 모든 제약 조건을 지켜야 REST를 따른다라고 할 수 있음.

2-4) REST를 구성하는 스타일

Client-server
Stateless
클러스터 또는 영구 스토리지에 데이터 또는 애플리케이션 상태를 저장하는 않는 애플리케이션임.
대신 데이터 및 애플리케이션 상태가 클라이언트에 유지되므로,
상태 비추적 애플리케이션은 확장성이 뛰어남.
Cache

- Uniform Interface(모든 제약 조건 중에 이 부분을 잘 만족시키지 못함)

Layered System
하부 층이 함수 및 기능과 상위 계층의 서비스를 지원하는 서비스를 제공하도록
계층적 배열로 계층화. 계속해서 증가하는 복잡성과 시스템은 여전히 제자리에 있는 구성요소를
사용하면서 전체 시스템 기능을 향상시키기 위해 계층을 추가하거나 변경하여 구축할 수 있음.
Code-On-Demand(Optional, 서버에서 코드를 클라이언트에게 보내서 실행한다는 의미)

→ 자바스크립트를 의미하는 거임.

→ REST는 아키텍처 스타일이면서 동시에 하이브리드 아키텍처 스타일이라고 말함.

⇒ 아키텍처 스타일인데, 동시에 아키텍처 스타일의 집합이기 때문.

2-5) Uniform Interface의 제약 조건(모든 제약 조건 중에 이 부분을 잘 만족시키지 못함)

Indentification of Resources

→ Resource가 URI로 식별되면 된다.

Manipulation of Resources Through Representations

→ Representation 전송을 통해 Resource를 조작해야 된다.

→ Resource를 저장, 수정, 삭제할 때 메시지에 담아 전송한다는 의미

Self-Descriptive Messages

→ 모든 REST API 중에 지키지 못하는 부분임.

→ Self-Descriptive라는 의미는 "메시지는 스스로를 설명해야 한다."

ex) HTTP 요청 메시지

// 목적지를 추가하지 않았을 때

GET / HTTP/1.1

-> 이 HTTP 요청 메시지는 뭔가 빠져 있어서 
-> Self-Descriptive하지 못하다.
-> 목적지가 빠져있음.

// 목적지를 추가했을 때 

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

-> 목적지를 추가하면 이제 Self-Descriptive

ex) 응답 메시지

// 컨텐츠의 유형을 몰랐을 때

HTTP/1.1 200 OK

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

-> 200 OK와 JSON으로 된 본분
-> 클라이언트가 이걸 받아서 해석해야되는데, 
-> 어떤 문법으로 작성된 걸 모르기 때문에 해석을 못함.

// 컨텐츠의 유형을 알았을 때

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

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

-> Self-Descriptive하려면 Content-Type Header가 반드시 
-> 들어가야 함. 대괄호 중괄호 큰따옴표의 의미를 해석하기 때문에 
-> 파싱이 가능해지고 문법을 해석할 수 있게 됨.

// 이걸 했다고 해서 Self-Descriptive라고 할 수 없음. 
// op와 path는 무엇을 의미하는지 모름.

// Self-Descriptive하다라는 것의 결론

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

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

-> json-patch라는 명세를 찾아가서 이걸 이해하고
-> 메시지를 해석한 후에야 메시지를 이해할 수 있음.

⇒ 오늘날 Content-Type: application/json으로만 되어 있기 때문에

⇒ 해석해야한다는 부분에서 알 수 없음.

Hypermedia As The Engine of Application state(HATEOAS)

→ 모든 REST API 중에 지키지 못하는 부분임.

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

ex) 애플리케이션 상태의 전이

→ Link를 따라가면서 전이했기 때문에 HATEOAS가 됨.

ex) HATEOAS

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

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

-> a Tag를 통해서 HyperLink가 나와있고 
-> 그 다음 상태로 전이가 가능해짐.

// HATEOAS를 JSON으로 표현했을 때 

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..."
}

-> Link라는 Header가 Resouce와 HyperLink로 연결되어 있는 다른 Resouce를 
-> 가리킬 수 있는 그런 기능을 제공해줌. 
-> 한 게시물을 JSON으로 표현한 것인데, 이전 게시물의 URI가 /articles/1이고 
-> 다음 게시물의 URI가 /articles/3이다라는 정보를 표현해줌. 
-> 이 정보는 Link Header가 표준으로 문서가 나와있기 때문에 
-> 이 메시지를 보는 사람이 먼저 해석을 해서 어떻게 Link가 되어 있는가를 
-> 이해하고 HyperLink를 타고 다른 상태로 전이가 가능함.  
=> 이것도 역시 HATEOAS를 만족한다라고 할 수 있음.

2-6) Uniform Interface의 사용이유

2-6)-1. 독립적 진화

→ 서버와 클라이언트가 각각 독립적으로 진화함.

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

→ REST를 만들게 된 계기 : 어떻게하면 Web을 망가뜨리지 않고

                                  HTTP를 한 단계 발전시킬 수 있을까?

⇒ 독립적인 진화를 하기 위해서는 Uniform Interface가 만족해야 됨.

3. WEB

3-1) WEB

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

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

HTTP 명세가 변경되어도 웹은 잘 동작함.

HTML 명세가 변경되어도 웹은 잘 동작함.

3-2) WEB은 어떻게 가능하게 했을까?

W3C Working groups

HTML을 만들어냄