REST

• REpresentational State Transfer
• a way of providing interoperability between computer systems on the internet
• improve HTTP without breaking the Web
• Roy T. Fielding 의 박사 논문 "Architectural Styles and the Design of Network-based Software Architectures"

WEB 의 3요소

1. HTML: 표현형식
2. URI: 식별자
3. HTTP: 전송방법

웹 API 의 역사

XML-RPC(1998) → SOAP (Simple Object Access Protocol)

• by Microsoft

SOAP 예시

• Salesforce API (2000)
• flickr API (2004)

SOAP vs REST

• SOAP: 복잡, 규칙 많음, 어렵다
• REST: 단순, 규칙 적음, 쉽다
• 결국 REST 가 승리

CMIS (2008)

• Content Management Interoperability Services
• CMS (Content Management System) 을 위한 표준
• EMC, IBM, MS 가 협력해서 만듬
• REST 바인딩을 지원
• 근데 로이 필딩 왈: No REST in CMIS

REST API 의 조건

• must be hyper-text driven (not json)
• versioning 이 필요없어야 함

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

REST 아키텍처: 웹을 위한 아키텍처 스타일

웹: 분산 하이퍼 미디어 시스템

자주 위반하는 REST 아키텍처 스타일

uniform interface

• self-descriptive message
• HATEOAS (Hypermedia As The Engine Of Application State)

핵심: interoperability

• 서버가 변경되어도, 클라이언트를 업데이트 할 필요가 없다.
• 서버와 클라이언트가 독립적으로 진화한다.

자주 위반하는 이유

REST 는 원래 "사람-기계"가 HTML 로 소통하기 위한 아키텍처이다.

백엔드 API는 "기계-기계" 가 json 으로 소통하고 있다.

REST 하지 않기에, self-descriptive 하지 않아서 별도의 API 문서가 필요하다.

개선안

Self-Descriptive

• 방법1: Media Type 을 명세해 놓기
• 방법2: Link 헤더에 profile relation 으로 명세서 링크 작성

HATEOAS

• 방법1: data에 하이퍼링크를 표현
• 방법2: Link, Location 헤더에 하이퍼링크를 표현

결론

REST API 라 부르는 대부분의 API 는 사실 REST 아키텍처를 따르지 않는다.

REST 아키텍처를 만족하려면 다음 두 조건을 만족해야한다.

• Self-descriptive
  • custom media type 혹은 profile link relation 활용하기
• HATEOAS
  • 헤더나 본문에 링크를 담아서 만족시키기

REST API 가 아니라 HTTP API 라고 부르자