그런 REST API로 괜찮은가 정리 아닌 정리

이 포스팅은 "네이버 데뷰 Day1, 2-2. 그런 REST API로 괜찮은가" 영상에 나온 내용을 정리 아닌 정리한 글입니다.

 

1991년 WEB이 탄생했을 당시 아래와 같은 고민이 존재했다.

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

A. 정보들을 하이퍼텍스트로 연결한다. 표현방식 HTML / 식별자 URI / 전송 방법 HTTP

 

HTTP 프로토콜 설계 당시

프로젝트에 참가한 대학원생 로이필딩은 다음과 같은 고민을 합니다.

"How do i improve HTTP without breaking the web?"

 

고민 끝에 만들어 진 것이 REST이다. 로이필딩은 REST를 박사 논문으로 발표하였다.

---

한편 인터넷 상에 API가 수면위로 등장하게 되었다. 마이크로소프트에서는 XML -  RPC(1998)라는 원격으로 다른 시스템의 메소드를 실행시킬 수 있는 프로토콜을 만든다. 이것이 SOAP이다. 세일즈포스는 SOAP을 통해 API를 만든다. 4년 뒤 API가 나왔다. 이들은 여러 형태로 API를 만들었따. SOAP 형태, REST 형태 그런데 SOAP에 비해 REST 형태가 매우 간단해보였다. 사람들이 느끼기에는 REST는 단순하고 규칙이적고 쉽다고 느껴졌다.

 

결국 06년 AWS의 자사 API의 사용량의 85%가 REST API임을 밝힌다. REST의 승리를 알리나 싶었는데 08년 MS, IBM, EMC 등 거대회사가 참여한 CMIS가 등장하게 된다. CMIS는 REST 바인딩을 지원한다.

 

하지만 REST를 만든 로이필딩은 이런 말을 한다. "No REST in CMIS" 

 

이후 Microsoft에서는 REST API 가이드라인을 발표하는데...

여기서도 로이필딩은 이건 REST API가 아니라 HTTP API라고 말한다.

 

이외 등등 로이필딩은 여기저기서 다양한 SNS에서 REST API가 아님을 지적한다.

 

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

REST : 분산 하이퍼미디어 시스템(예 : 웹)을 위한 아키텍처 스타일

(개인 설명 추가) 하이퍼미디어란 문서나 미디어 자료를 링크를 통해 서로 연결된 형태로 구성한 것을 말합니다.

 

아키텍처 스타일이란? 제약조건의 집합, 이것을 모두 준수해야 REST를 따른다고 말한다.

 

REST를 구성하는 스타일

• client-server
• stateless
• cache
• uniform interface
• layered system
• code-on-demand(optional)

오늘날의 REST API라 불리는 것들의 위 스타일을 대체로 잘 지킨다. 왜냐하면 HTTP만 잘따라도 client-server, stateless, cache, layered system, code-on-demand을 지킬 수 있다. code-on-demand란 서버에서 코드를 클라이언트로 보내서 실행할 수 있어야 된다는 것을 의미한다.

---

그런데 오늘날의 REST API가 잘 지키지 못하는 것은 uniform interface이다.

 uniform interface의 제약조건은 아래와 같다.

• identification of resources (리소스가 URI로 식별되면 된다.)
• manipulation of resources through representations (클라이언트가 서버의 자원을 조작(수정, 삭제, 생성 등)하기 위해 요청을 보낼 때, 그 자원에 대한 표현(representation)을 함께 보내야 한다는 의미입니다. HTTP 메소드(PUT, GET, DELETE 등을 의미))
• self-descriptive messages
• hypermedia as the engine of applicataion state(HATEOAS)

 

 

self-descriptive messages

메시지는 스스로를 설명해야 한다. 쉽게 말해 메시지 자체로 설명이 온전히 가능해야 한다.(자의적인 해석이 필요없다.) 예시를 통해 알아보자.

 

이 예시는 self-descriptive messages 하다고 말하기 어렵다. 왜냐하면 서버에서는 요청자가 어떠한 형식으로 데이터를 내려줘야 할 지 클라이언트의 의도를 추측해야 하기 때문이다. 메세지가 스스로를 설명하지 못한다는 것이다.

조금 더 REST스럽게 만들어보자.

 

 

hypermedia as the engine of applicataion state(HATEOAS)

애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다. 아래와 같이 서버의 응답을 받았을 때 현재 자원과 연관된 자원에 대한 링크 정보가 포함되어 있어야 합니다.

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

{
  "id": 123,
  "name": "Product123",
  "price": 20000,
  "links": [
    {
      "rel": "self",
      "href": "/api/products/123"
    },
    {
      "rel": "category",
      "href": "/api/categories/1"
    },
    {
      "rel": "related",
      "href": "/api/products?category=1"
    }
  ]
}

Q.그렇다면 왜 Uniform interface를 지켜야 할까요?

A.독립전 진화

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

 

REST가 지켜지고 있는 사례 - 웹

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

 

REST가 안지켜지고 있는 사례 - 앱

 

앱의 경우 버전이 업그레이드 되면 업데이트가 필요한 경우가 많다.

 

웹은 어떻게 이런걸 가능하게 한걸까요?

• 놀라운 마법으로 한방에 해결 (x)
• 피땀흘려 노력함 (o)