그 REST API는 REST한가? (2/2)

주영익

부제:

당신이 만든 건 REST가 아니지만 괜찮아

문제:

나도 REST 논문은 안 읽어 봤지만 괜찮...

지난 시간에 우리는

HTTP/1.1

2014년 6월 개정

​

RFC 7230, HTTP/1.1: Message Syntax and Routing

RFC 7231, HTTP/1.1: Semantics and Content

RFC 7232, HTTP/1.1: Conditional Requests

RFC 7233, HTTP/1.1: Range Requests

RFC 7234, HTTP/1.1: Caching

RFC 7235, HTTP/1.1: Authentication

HTTP Method - CRUD

출처 : http://www.pybloggers.com/2017/05/test-driven-development-of-a-django-restful-api/

REALLY?

POST vs PUT

요청 URI의 다른 의미

• RFC2616

동봉된 representation에 대한 다른 의도

• RFC7231

Response Status Codes

1xx

• 정보

2xx

• 성공

3xx

• 리다이렉션

4xx

• 클라이언트 에러

5xx

• 서버 에러

헤더 - 주요 헤더

요청

• Cookie : 서버에 의해 Set-Cookie로 클라이언트에게 설정된 쿠키 정보
• Referer : 바로 직전에 머물렀던 웹 링크 주소
• User-Agent : 클라이언트 소프트웨어(브라우저) 명칭 및 버전 정보
• Accept : 클라이언트 자신이 이해 가능한 미디어 타입 및 우선순위
• Accept-Charset : 클라이언트 자신이 이해 가능한 문자 인코딩 방식
• Accept-Encoding : 클라이언트 자신이 이해 가능한 압축 방식
• Accept-Language : 클라이언트 자신이 이해 가능한 언어
• If-Modified-Since : 제시한 일시 이후에 만 해당 리소스를 취득 요청

Representation

어떤 리소스의 특정 시점의 상태를 반영한 정보

왜 HTML Form에서는 PUT과 DELETE를 지원하지 않는가

REST

REpresentational State

Transfer

Representation

• 어떤 리소스의 특정 시점의 상태를 반영하고 있는 정보
• 내용 협상(Content negotiation)을 통해 선택됨
• Content-Type: text/plain
• Content-Language: ko

State Transfer

Web Application

State Transfer

Web Application

State Transfer

State Transfer

REpresentational State

Transfer

이게 무슨...

효율적이고 확장성있는 시스템

만들기

어떻게?

Representation

Hypermedia

REST는 웹에 한정된 기술인가?

REST는 웹에 한정된 기술인가?

• 아니다

​

• 최초에 웹을 염두에 둔 것은 맞다

​

• REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다 - wikipedia

​

• 웹이 아닌 것에 적용해도 되는데 웹에 딱 들어맞는다

​

• 그런데 웹이 아닌 것에 적용된 걸 본 적이 있나?

Fielding Dissertation

웹을 염두에 두고 만들었지만 웹에만 한정되지 않는다는 걸 기억하면서

Deriving REST

6 Constraints

0. Starting with the Null Style
1. Client-Server
2. Stateless
3. Cache
4. Uniform Interface
5. Layered System
6. Code-On-Demand

1. Client-Server

• Client-Server 구조
• Client가 요청을 발생
• 관심사의 분리
• UI - Data storage 분리
• 독립적인 진화

2. Stateless

• No session state on server
• 가시성, 신뢰성, 확장성

3. Cache

• Cache할 수 있는지, 없는지 나타내기

4. Uniform Interface

• 구성 요소간 균일한 인터페이스
• 4 Interface Constraints
• identification of resources
• manipulation of resources through representations
• self-descriptive messages
• hypermedia as the engine of application state

4. Uniform Interface

4 Interface Constraints

• Identification of resources
• 일관된 자원 식별 방법
• Resource == anything

4. Uniform Interface

4 Interface Constraints

• Manipulation of resources through representation
• 자원의 추상적 정의
• Cool URIs don’t change
• 리소스의 표현을 식별자로부터 분리함
• 동일한 URI에서 동일한 자원에 대한 표현을 둘 이상 지원 가능

4. Uniform Interface

4 Interface Constraints

• Self-descriptive messages
• 요청이나 응답 메시지에는 이를 이해하기 위한 모든 정보가 포함되어야 한다

HTML vs JSON

content-type: text/html

• Syntactically, semantically understandable

HTML vs JSON

content-type: application/json

• Syntactically, semantically understandable

JSON API

JSON API

JSON-LD

4. Uniform Interface

4 Interface Constraints

• Hypermedia as the engine of application state
• 다음 액션에 대한 선택지를 클라이언트에게 줘야한다
• Out-of-band 정보 없이 client가 주도할 수 있는 충분한 힌트
• 위대한 WWW를 보라

HATEOAS

어떻게 읽어야 하나요? https://www.howtopronounce.com/hateoas/

Hypertext라고 불러보자.

응답에 링크를 제공하는 것은 HATEOAS가 아니고 그냥 링크가 있는 응답일 뿐.

Why I Hate HATEOAS

REST는 뭐다?

Architectural style for distributed hypermedia systems

5. Layered System

• 미들웨어 구성요소를 추가할 수 있는 구조
• Server-Client 간 상호 작용을 일관성있게 유지해야 함
• 중간에 구성요소가 추가됐는지, 다른 서비스와 추가로 통신하는지 관심없음

6. Code-On-Demand (Optional)

• Script 등 추가 다운로드/실행을 통한 기능 확장
• 따라서 가시성을 떨어뜨림
• 따라서 Optional

끝

ㅇㅇ끝

Anti-REST

Anti-REST

1. 재미있는 글을 발견함
• “RESTful APIs, the big lie”

Problems of REST

#1: There is little agreement on what a RESTful API is

#2: The REST vocabulary is not fully supported

#3: The REST vocabulary is not rich enough for APIs

#4: RESTful APIs are very hard to debug

#5: RESTful APIs are usually tied to HTTP

​

The way forward: JSON-Pure APIs

Anti-REST

• 재미있는 글을 발견함
• “RESTful APIs, the big lie”
• “그래, 공감이 되네”

Anti-REST

​

• 재미있는 글을 발견함
• “RESTful APIs, the big lie”
• “그래, 공감이 되네”
• 댓글을 읽기 시작
• “그건 REST가 아니지”
• “REST가 아니지가 아니지”
• 풍부한 개싸움

Myths

미신 : REST는 4가지 HTTP 메소드를 쓰는 것

첫째, HTTP 메소드는

조회 = GET / 등록 = POST / 수정 = PUT / 삭제 = DELETE

와 같이 매핑되지 않는다.

​

이건 REST 문제가 아니라 HTTP의 문제.

미신 : REST는 4가지 HTTP 메소드를 쓰는 것

둘째, REST에서는 클라이언트가 어떤 메소드로든 시도할 수 있다.

서버가 어떤 메소드를 지원하는지 알아야 한다면 이는 out-of-band 정보이며,

RESTful하지 않다.

​

서비스하지 않는 메소드로 요청이 왔을 때, 서버는 405 Method Not Allowed를 리턴하면 된다.

미신 : REST는 4가지 HTTP 메소드를 쓰는 것

셋째, REST는 사실 HTTP에 종속되어 있지도 않다.

​

웹에서의 주요 프로토콜이 HTTP이고, 여기에 많은 영향을 많이 받았지만,

REST는 HTTP에 한정되지 않는다. (5.3.2 Connector View 참고)

​

사용하는 프로토콜 표준을 잘 지키는 것이 핵심.

미신 : REST는 좋은 URL에 관한 것이다

RESTful한 URI같은 건 없다.

​

/v1, /v2... 버저닝 필요없다.

• Cool URIs don’t change!!
• 네? 버저닝이 필요하시다고요? 왜죠?

​

미신 : REST는 좋은 URL에 관한 것이다

RESTful한 URI같은 건 없다.

​

/class/A/student/123/study-hard… depth를 구성할 필요없다.

• 계층 정보를 몰라도 hypertext를 통해 리소스를 찾아가는 것이 좋다
• URI 템플릿을 제공하는 방법도 있다
• 클라이언트가 다음 행동을 결정하기 위한 충분한 정보를 제공하자

​

미신 : HTML Form에서 지원하지도 않는다

HTTP와 HTML을 동시에 다루는 개발자들이 혼란스러울 뿐.

HTML의 Form에서는 PUT/DELETE를 제공할 의무가 없다.

그리고 그건 REST의 잘못이 아니다.

​

미신 : HTTP 메소드와 응답코드는 이해하기 어렵다

현실적으로 이야기 하자면 그럴 수 있다.

당신 회사만의 클라이언트를 위한 API를 만들 때는 적당히 알아서 하시라.

하지만 광범위한 클라이언트에 대응하려면 표준이 필요하고 따를 필요가 있다.

왜 그 훌륭한 개발자들이

오해를 하고 있을까?

ROA

Resource-Oriented Architecture

ROA는 REST 기반 웹서비스를 만들기 위한 문제점을 해결하는 방법을 제공한다.

​

ROA는 RESTful 아키텍처이다.

​

• [REST] The Resource-Oriented Architecture

ROA

• RESTful Web Services
• Leonard Richardson
• 한국어 번역서는 절판
• Richardson Maturity Model
• Martin Fowler의 소개글
• 지앤선의 번역글

REST가 잘못 이해되었다는 건 알겠는데 이제 어떡하지?

REST에 대한 진실을 알아버린 당신의 선택은?

1. 못 본 척한다

• Pogi.Hamyun.Pyunhae.
• 어떤 것을 REST가 아니라고 이해시키기엔 너무 많은 노력이 필요하다
• 모두를 위해 Mr. Fielding만 사라지면 된다
• 그런데 하필 그 사람이 REST를 만들었네
• 인류는 항상 대를 위해 소를 희생하지 않았던가!

로이 필딩이 면접에서 REST에 관한 질문을 받는다면?

그건 REST가 아니야

됐어

넌 탈락이야

REST에 대한 진실을 알아버린 당신의 선택은?

2. RESTful하지 않으면 REST라고 부르지 않는다

• 어렵지만 완벽한 해결책
• REST란 용어를 잘못 이해하고 사용하면 커뮤니케이션에 방해가 된다
• 하지만 제대로 알고 사용해도 (현실적으로) 커뮤니케이션이 안 되긴 마찬가지
• 용기를 갖자고요

하지만

우리

싸우지 말아요

선풍기 사망설

• 잘 모르겠지만 검증하긴 어렵다
• 텔레비전에 누가 나와서 틀고 자면 죽는다고 했다
• 검증하기 귀찮은데 죽기도 싫다
• 얼마나 많은 과학 ‘상식’이 거짓으로 밝혀졌는가?
• 선풍기 사망설을 믿으면 똥멍청이인가?

압존법

• 저는 압존법 모범생이었습니다
• Since 국딩 ~ 2016년 겨울
• 여러분 압존법 쓰지 마세요
• 표준화법해설(1992)
• “가정 내에서도 압존법을 지켜도 되고 안 지켜도 된다.”
• 표준 언어 예절 - 경어법(2011)
• “...직장에서 쓰는 것은 어색하다”

압존법

• 저는 압존법 모범생이었습니다
• Since 국딩 ~ 2016년 겨울
• 여러분 압존법 쓰지 마세요
• 표준화법해설(1992)
• “가정 내에서도 압존법을 지켜도 되고 안 지켜도 된다.”
• 표준 언어 예절 - 경어법(2011)
• “...직장에서 쓰는 것은 어색하다”

전역하고 알아서 다행이다

“압존법은 표준 화법이 아니지 말입니다"

그들이 사는 법

당신이 만든 건 REST가 아니지만 괜찮아

Your API isn’t RESTful

• ...And That’s Good
• https://medium.com/@trevorhreed/you-re-api-isn-t-restful-and-that-s-good-b2662079cf0e
• A New Name, An Old Concept
• 우리가 원하는 그것을 RESOURCEful API라고 부르자

Your API isn’t RESTful — And That’s Good

사람들은 SOAP 같은 프로토콜 대신 간단하고 표준적인 대안을 원했다.

​

REST의 아이디어 중 일부는 필요에 잘 부합했지만 전부는 아니었다.

​

그래서 사람들은 필요한 것을 가져갔고 나머지는 무시했다.

​

그들은 REST란 용어를 납치했다.

​

Your API isn’t RESTful — And That’s Good

REST라면 서버와 클라이언트가 강하게 결합하지 않아야만 한다.

​

클라이언트는 서버가 제공하는 하이퍼미디어를 탐색하는 방법만 이해하면 된다.

​

가장 일반적인 예는 월드 와이드 웹이다.

​

많은 웹 API는 클라이언트와 강하게 결합되어 있고 하이퍼미디어가 부족하기 때문에 REST의 원칙을 위반한다.

​

​

Your API isn’t RESTful — And That’s Good

우리에게 필요한 건 웹 API의 일반적인 사용 사례를 공식적으로 정의하고 표준화 하기.

​

이 모든 혼란을 종식하기 위해 그 개념을 새로 명명해야한다.

​

이를 통해 강력한 표준 및 모범 사례를 구축할 수 있다.

​

진짜가 나타났다

REST를 제대로 구현하려는 사람들

Hypertext와 self-descriptive messages를 제공하는 여러 방법

• HAL http://stateless.co/hal_specification.html
• SIREN https://github.com/kevinswiber/siren
• SVG, Atom, (X)HTML(!)
• JSON Hyper-Schema http://json-schema.org/
• JSON API http://jsonapi.org/
• UBER Hypermedia http://uberhypermedia.org/

​

대체품 : GraphQL

GraphQL

Facebook에서 만들었고, 문법은 표준으로 관리되고, Github이 GraphQL로 서비스 하기로 했고, N+1 문제를 해결한다나 뭐라나, Netflix는 Falcor라는 놈을 만들었었고...

GraphQL

이런 Pseudo-REST API가 있다고 치고

GraphQL로 바꿔볼까요?

GraphQL

타입을 정의합니다

이런 걸 스키마(Schema)라고 불러요

GraphQL

쿼리 타입을 정의합니다

book, author라는 쿼리 타입이 있네요

GraphQL

짠

GraphQL

이런 저런 장점과 그렇고 그런 단점이 있습니다.

그러나 Pseudo-REST API가 이루지 못한 REST의 교훈을 떠올려 봅시다.

​

GraphQL

구현하기 더 쉽다

커플링을 약간은 없애주기도 한다

Cache는 좀 약하죠

Client / Server 모두 이해할 수 있는 실시간 표준

주고 받는 데이터 자체에 집중

​

대체품 : OAI

OpenAPI Initiative

나 MS야

Microsoft REST API Guidelines

Note: The guidelines are designed to align with building services which comply with the REST architectural style, though they do not address or require building services that follow the REST constraints. The term "REST" is used throughout this document to mean services that are in the spirit of REST rather than adhering to REST by the book.

결론

REST란 용어에 집착하지 않기

REST의

5가지 제약사항에 집착하지 않기

REST의 교훈을 받아들이기

니가 진짜로 원하는 게 뭐예요?

Q & ...