Portfolio

NAVER DEVIEW 2017 에서 공유되었던 내용입니다.

영상 링크

슬라이드 링크

💡

REpretational State Transfer A way of providing interoperability between computer systems on the internet

WEB (1991) - 팀 버너스-리

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

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

HTTP/1.0 (1994~1996)

로이 필딩 : “How do i improve HTTP without breaking the Web?”

→ HTTP Object Model

→ REST(1998) Microsoft 에서 발표

→ REST(2000) 로이 필딩의 박사 논문 (120 페이지, 지루하다)

API

XML-RPC (1998), by Microsoft → soap

Salesforce API(2000.2) : SOAP API 공개

Flickr API(2004.8) : SOAP API, REST API둘다 공개

REST 의 승리~~~ 와~~~

그런데...

CMIS (2008)

CMS를 위한 표준

EMS, IBM, MS 등이 함께 작업

REST 바인딩 지원

로이 필딩 : “이건 REST 가 아니야!!!!!!”

Microsoft REST API Guidelines (2016)

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

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

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

등등...

로이 필딩 : “이건 REST 가 아니라고!!!!!!!!!!!!!”

로이 필딩

“REST APIs must be hypertext-driven”

“REST API를 위한 최고의 버저닝 전략은 버저닝을 안 하는 것”

REST API

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

REST

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

아키텍쳐 스타일

제약조건의 집합

REST를 구성하는 제약조건/스타일

client-server

stateless

cache

uniform interface

identification of resources
manipulation of resourcces through representations
self-descriptive messages
hypermedia as the engine of application state (HATEOUS)

layered system

code-on-demand (optional)

서버에서 코드를 보내서 클라이언트에서 실행 할 수 있어야함 (자바스크립트)

Self-descriptive message

GET/ HTTP/1.1

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


GET / HTTP/1.1
host: www.eample.org

목적치를 추가하면 이제 self-descriptive


HTTP/1.1 200OK

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

Self-descriptive하지 않은 응답메시지임


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

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

조금 더 Self-descriptive한 응답메시지임


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

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

Self-descriptive한 응답메시지임

HATEOAS

💡

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

HATEOAS


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

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


HTTP/1.1 200OK
Content-Type: text/html
Link: </article/1>; rel="previous",
			</article/3>; rel="next";

{
	"title": "The second article",
	"contens" : "내용 내용..."
}

왜 Uniform Interface??

독립적인 진화

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

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

REST를 만들게 된 계기 - “How do I improve HTTP witout braking the WEB”

웹

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

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

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

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

상호운용성(interoperability)에 대한 집착

Referer 오타지만 안 고침

charset 잘못 지은 이름이지만 안 고침

HTTP 상태 코드 416

HTTP/0.9 아직도 지원함 (크롬, 파이어폭스)

결국 REST는 목적을 달성하고 성공함

HTTP 규약의 작성에 영향도 줌

근데 REST API는??

너무 어려워.... 그냥 REST 하지 말까?

어떻게 할까?

REST API를 구현하고 REST API라고 부른다

REST API의 구현을 포기하고 HTTP API라고 부른다

REST API가 아니지만 REST API라고 부른다.

API가 REST로 만들기 어려운 이유

HTML vs JSON

별도의 API 문서 필요

비교

HTML

JSON

그런 REST API로 괜찮은가

WEB (1991) - 팀 버너스-리

HTTP/1.0 (1994~1996)

API

Self-descriptive message

HATEOAS

왜 Uniform Interface??

근데 REST API는??

어떻게 할까?

API가 REST로 만들기 어려운 이유