그런 REST API로 괜찮은가

작성일 | In

먼저, 알고가야할 것 : REST는 형식이기 때문에 기술에 영향을 받지 않는다.

REST의 역사

WEB(1991)

Q : 어떻게 인터넷에서 정보를 공유할 것인가?
A : 정보들을 하이퍼텍스트로 연결한다.

  • 표현 형식 : HTML
  • 식별자 : URL
  • 전송방법 : HTTP

HTTP 프로토콜를 설계하게 됨

HTTP/1.0(1994-1996)

당시 상황

  • 이미 HTTP는 WWW에 전송 프로토콜로 사용
  • 웹은 급속도로 성장하는 도중

Roy T.Fielding(이때는 대학원생 신분)

  • HTTP를 구축한다면 기존의 웹과의 호환성 문제

Q : “How do I improve HTTP without breaking the web?”
A : HTTP Object Model

REST(1998)

Roy T.Fielding, HTTP Object Model을 REST라는 이름으로 1998년도에 Microsoft Research에서 발표

REST(2000)

Roy T.Fielding, 박사 논문으로 발표
이 논문이 우리가 알고 있는, 정의하고 있는 REST에 대한 내용이다.


API의 역사

XML-RPC(1998)

Microsoft에서 원격으로 다른 시스템의 메소드를 호출할 수 있는 RPC라는 프로토콜을 만들었다.
나중에 SOAP이라는 이름으로 바뀐다.

Salesforce API(2002.2)

Salesforce라는 회사에서 API를 공개했다.
인터넷에서 최초로 공개된 API라고 볼 수 있다.
너무 복잡했기 때문에 인기가 없었다.

flickr API(2004.8)

flickr라는 회사에서도 API를 공개했다.
SOAP과 REST 두 가지 형태로 API를 만들었다.
SOAP과 REST의 느낌적인 비교

SOAP REST
복잡하다 단순하다
규칙 많음 규칙 적음
어렵다 쉽다

* 나중에 오해였다는 것을 알게 된다. 어느 부분인지는 뒤에서 확인해보자!

그 결과

  • 2006년, AWS가 자사 API의 사용량의 85%가 REST임을 밝힘
  • 2010년, Salesforce.com, REST API 추가

CMIS(2008)

  • CMS를 위한 표준
  • EMC, IBM, Microsoft 등이 함께 작업
  • REST 바인딩 지원

=> Roy T. Fielding : “No REST in CMIS”

Microsoft REST API Guidelines(2016)

  • uri는 https://{serviceRoot}/{collection}/{id} 형식이어야한다.
  • GET, PUT, DELETE, POST, HEAD, PATCH, OPTIONS를 지원해야한다.
  • API 버저닝은 Major.minor로 하고 uri에 버전 정보를 포함시킨다.
  • 등등..

=> Roy T. Fielding : “이것도 REST API가 아님. 이건 HTTP API이다.”

Roy T. Fielding
“REST APIs must be hypertext-drive”
“REST API를 위한 최고의 버저닝 전략은 버저닝을 안 하는 것”

사람들이 알고 있는 REST API와 Roy T.Fielding이 말하는 REST API가 다르다. 뭐가 문제인 걸까요?

REST API

REST 아키텍쳐 스타일을 따르는 API
* REST : 분산 하이퍼미디어 시스템(예: 웹)을 위한 아키텍쳐 스타일
* 아키텍쳐 스타일 : 제약조건의 집합

REST를 구성하는 스타일

  • client-server
  • stateless
  • cache
  • uniform interface
  • layered system
  • code-on-demand (optional) : 서버에서 코드를 클라이언트한테 보내서 실행할 수 있어야한다.(자바스크립트)

대부분은 HTTP 프로토콜의 조건만 지키면 다 지켜지지만 단 하나, uniform interface가 지키기 어렵다.

Uniform Interface의 제약조건

  • resources가 uri로 식별되면 된다. (잘 지켜짐)
  • representations 전송을 통해서 resources를 조작해야한다. (잘 지켜짐)
  • self-descriptive messages (거의 지키지 못함)
  • hypermedia as the engine of application state(HATEOAS) (거의 지키지 못함)

self-descriptive messages

메시지는 스스로를 설명해야한다.

예제 1.
GET / HTTP/1.1 목적지가 빠져있어서 self-descriptive 하지 않는다.

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

예제 2.

1
2
3
HTTP/1.1 200 OK

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

클라이언트가 어떤 문법으로 작성되어있는 지 몰라서 해석을 못한다.
Content-Type : application/json을 넣어주면 [],{},”“의 뜻들을 알 수 있다.
Content-Type : application/json-patch+json을 넣어주면 patch+json 명세에 찾아가서 op, path의 뜻을 알 수 있다.

1
2
3
4
HTTP/1.1 200 OK
Content-Type : application/json-patch+json

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

예제 3.

HATEOAS

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

왜 Uniform Interface을 해야하는 가?

독립적 진화를 하기 위해서

  • 서버와 클라이언트가 각각 독립적으로 진화한다.
  • 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
  • REST를 만들게 된 계기 : “How do I improve HTTP without breaking the Web”

웹 - REST API를 매우 잘 만족함

  • 웹 페이지를 변경했다고 웹 브라우저를 업데이트할 필요는 없다.
  • 웹 브라우저를 업데이트했다고 웹 페이지를 변경할 필요도 없다.
  • HTTP 명세가 변경되어도 웹은 잘 동작한다.
  • HTML 명세가 변경되어도 웹은 잘 동작한다.

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

  • HTTP에 지속적으로 영향을 줌
  • Host 헤더 추가
  • 길이 제한을 다루는 방법을 명시 (414 URI Too Long 등)
  • URI에서 리소스의 정의가 추상적으로 변경됨 : “식별하고자 하는 무언가”
  • 기타 HTTP와 URI에 많은 영향을 줌
  • HTTP/1.1 명세 최신판에서 REST에 대한 언급이 들어감
  • Reminder : Roy T. Fielding이 HTTP와 URI 명세의 저자 중 한명이다.

그럼 REST는 성공했는 가

성공!

  • REST는 웹의 독립적 진화를 위해 만들어졌다.
  • 웹은 독립적으로 진화하고 있다.

REST API는?

  • REST API는 REST 아키텍쳐 스타일을 따라야한다.
  • 오늘날 스스로 REST API라고 하는 API들의 대부분이 REST 아키텍쳐 스타일을 따르지 않는다.
    • Q : REST API도 저 제약조건들을 다 지켜야 하는 건가?
    • A : 그렇다.
  • Roy T. Fielding : “REST API는 하이퍼텍스트를 포함한 self-descriptive한 메시지의 uniform interface를 통해 리소스에 접근하는 API이다.”

이제서야 밝혀지는 오해

SOAP REST
복잡하다 단순하다
규칙 많음 규칙 적음
어렵다 쉽다(x) => 어렵다

원격 API가 꼭 REST API여야 하는 건가?

  • 아니여도 된다.
  • Roy T. Fielding : “시스템 전체를 통제할 수 있다고 생각하거나, 진화에 관심이 없다면, REST에 대해 따지느라 시간을 낭비하지 마라”

그럼 현재는?

  1. REST API를 구현하고 REST API라고 부른다.(도전)
  2. REST API 구현을 포기하고 HTTP API라고 부른다.
  3. REST API가 아니지만 REST API라고 부른다.(현재 상태)


REST API 구현

왜 API는 REST가 잘 안되나(웹과 비교)

  흔한 웹 페이지 HTTP API
Protocol HTTP HTTP
커뮤니케이션 사람-기계 기계-기계
Media Type HTML JSON
  HTML JSON
Hyperlink 됨(a 태그 등) 정의되어있지 않음
Self-descriptive 됨(HTML 명세) 불완전*

* 문법 해석은 가능하지만, 의미를 해석하려면 별도로 문서가(API 문서 등) 필요하다.

REST API가 만족해야하는 조건

Self-descriptive

확장 가능한 커뮤니케이션 : 서버나 클라이언트가 변경되더라도 오고가는 메시지는 언제나 self-descriptive 하므로 언제나 해석이 가능하다.

실패한 JSON

해결방법

HATEOAS

애플리케이션 상태 전이의 late binding : 어디서 어디로 전이가 가능한지 미리 결정되지 않는다. 어떤 상태로 전이가 완료되고 나서야 그 다음 전이될 수 있는 상태가 결정된다. 쉽게 말해서 링크는 동적으로 변경될 수 있다.

실패한 JSON

해결방법

=> HATEOAS는 data, 헤더 모두 활용하면 좋다.

참고