DEVIEW 2017 [SESSION 2] 그런 REST API로 괜찮은가

DAY 1 / 12:00~12:45 / TRACK 2

그런 REST API로 괜찮은가

서문

SOAP, REST 끝에 REST 승리

각종 가이드라인이 나왔지만 정작 REST 논문 작성자 로이 필딩은 부정함

REST 를 구성하는 스타일

• client-server

• stateless

• cache

• uniform interface

• layered system

• code-on-demand

Uniform interface?

self-descriptive messages, HATESOAS 를 지키지 못하고 있다.

- Self-descriptive message(자기소개)

메시지는 스스로 설명할 수 있어야 한다(메시지 내용만으로 온전히 해석이 모두 가능해야 한다)

- HATEOAS(다음상태)

애플리케이션의 상태가 hyperlink 로 전이될 수 있어야 한다.

json 의 경우 Link 라는 헤더가 있다.

왜 해야하나?

독립적 진화

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

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

• 만든이유: How do I improve HTTP without breaking the Web.

웹

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

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

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

• HTML 명세가 변경되어도 웹은 잘 동작한다(기본은).

상호운용성에 대한 집착

• Referer: 오타지만 못고침

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

• HTTP 상태코드 416 포기함(I'm teapot)

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

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

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

• Host 헤더 추가

• 길이제한을 다루는 방법이 명시 (414 URI too long)

• URI 에서 리소스 정의가 추상적으로 변경됨

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

• HTTP 1.1 명세 최신에서 REST 에 대한 언급을 함

REST 를 써야되나?

시스템 전체를 통제할 수 있거나 진화에 관심이 없다면 쓰지 않아도 된다( 로이 필딩 )

그럼이제 어떻게 할까(ㅋㅋ)

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

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

3. REST API 가 아니지만 REST API 라고 부른다(현재상태)

비교

• 웹 페이지(HTML)

  • HTTP, 사람 - 기계

  • 하이퍼링크 O, Self-descriptive O

  • 특정된 문법에 따라 Self descriptive 하게 읽을 수 있다.

• HTTP API(JSON)

  • HTTP, 기계 - 기계

  • 하이퍼링크 X, Self-descriptive 불완전

  • 구조에 대한 문법만 있기 때문에 값들이 무슨 의미를 가지는지 알 수 없다.

교정해보자(Self-descriptive)

방법1: Media type

미디어 타입을 하나 정의한다.

미디어 타입 문서를 작성한다. 이 문서에 의미를 정의한다.

IANA 에 미디어 타입을 등록한다. 문서를 미디어 타입 명세로 등록한다.

명세를 찾아가 해석할 수 있게 된다.

방법2: Profile

문서의 의미를 정의한 명세를 작성한다.

Link 헤더에 profile relation 으로 해당 명세를 링크한다.

명세를 찾아갈 수 있으므로 문서의 의미를 해석할 수 있다.

교정해보자(HATEOAS)

방법1: data

data에 다양한 방법으로 하이퍼 링크를 표현한다.

JSON 으로 하이퍼링크를 표현하는 방법을 정의한 명세들을 활용한다.

방법2: HTTP 헤더로

Link, Location 같은 헤더로 표현한다.