그런 REST API로 괜찮겠어?

왱구·2024년 3월 28일
스터디

스터디

목록 보기
13/21

참조 : https://www.youtube.com/watch?v=RP_f5dMoHFc&ab_channel=NAVERD2

1. REST란 무엇인가?

REST 많이 봐왔지만 REST가 뭔지 설명이 안되고 이해가 안된다. 전문가들이 "REST 스럽지 않은 것 같아요 .. REST API 가 아닌거같은데 ..?" 라고 말하는 가운데 REST는 어떤 의미일까?

1) REST의 정의

  • REpresentational State Tranfer
  • A way of providing interoperability between computer system on the Internet.
    "컴퓨터 시스템 간 상호운용성을 제공하는 방법"

2) REST의 배경

WEB (1991)

어떻게 인터넷에서 정보를 공유할 것인가에 대한 해답으로 웹이 나왔는데 모든 정보들을 하이퍼텍스트로 연결하여 제공을 하면 될 것이라고 생각하였다.
HTML이라는 표현형식으로 정보들을 표현하고
URI이라는 정보들에 대한 식별자로 URI 만들었고
HTTP이라는 전송방법으로 HTTP라는 프로토콜까지 만들었다.

HTTP Object Model

1994년, 여러사람들이 HTTP라는 프로토콜을 설계하는 가운데 HTTP프로토콜 1.0 작업에 참여중인 Roy T.Fielding는 의문을 가진다.

"How do I improve HTTP without breaking the Web?"
"내가 HTTP를 개선하면 웹이 깨질거같은데? 웹을 안깨먹고 HTTP를 개선하는 방법이 있을까?"

HTTP 1.0명세가 나오기 전에 이미 HTTP는 WWW의 전송 프로토콜로서 이용되고있었다. 웹은 급속도로 성장중이였고 이미 전세계에 수많은 웹서버가 존재했다.
Roy T.Fielding은 HTTP를 정립하면서 명세의 기능을 더하고 기존의 기능을 개선해야하는 상황에 놓였다. HTTP를 정립없이 HTTP 프로토콜을 개선하게되면 기존에 구축되어있던 웹과 호환성문제가 생길것이다.
어떻게하면 웹을 망가뜨리지않고 HTTP를 고칠 수 있을까? Roy T.Fielding은 그에 대한 해답으로 'HTTP Object Model'이라는 표준을 만들게 된다.

REpresentational State Transfer

이것은 1998년, Roy T.Fielding에 의해 'Representational State Transfer'라는 이름으로 발표된다.
이를 2000년, Roy T.Fielding이 다시 박사논문으로 발표하게되는데
이 논문이 우리가 오늘날 알고있는 'REST'라고 하는것을 정의하는 논문이다.

2. API란 무엇인가?

1) API의 정의

  • Application Programming Interface
  • 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘

2) API의 배경

1998년에 Microsoft에서 XML-RPC라는 원격으로 단일시스템의 메소드를 호출할 수 있는 프로토콜을 만들었다. 이는 나중에 SOAP이라고 바뀌게 된다.
이 SOAP를 사용해서 2000년에 Salesforce라는 회사에서 API를 공개하게 되는데 이게 최초의 API이다. 하지만 이는 어떤ID로 오브젝트 하나 가져오는데만 해도 너무 복잡해서 인기가 없었다.
4년 후 flickr에서만든 API는 형태가 여러가지 였는데 SOAP형태와 REST형태를 만들었다. SOAP을 보다가 REST를 보니 훨씬 짧고 간결했고 사람들은 이 둘을

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

라고 비교하게된다.
이는 결국

이런 결과로 이루어졌다.

REST API는 REST하지 않다?

2006년 AWS가 자사 API의 사용량의 85퍼센트가 REST임을 발표했고
2010년 결국 Salesforce조차 REST API를 추가했다. 이렇게 WWW의 API가 REST로 정착이 되는듯 했다.
그러나 2008년에 CMS를 위한 표준인 'CMIS'이 나오게 된다. EMC, IBM, Microsoft 등이 함께 작업했고 REST 바인딩을 지원했다.
근데 Roy T.Fielding은 이를 보고 CMIS에 REST는 없다 라고 이야기했다.

2016년에 Microsoft가 REST API 가이드라인을 만들었는데

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

등을 제시했고 사람들은 이것이 합리적인것 처럼 보였고 흔히 알고있는 REST에 부합하는거 같았다.
하지만 Roy T.Fielding은 이것 또한 REST API가 아니라고 말했고 HTTP API라고 해야한다고 하며

  • REST API는 반드시 hypertext-driven이어야 한다.
  • REST API를 위한 최고의 버저닝 전략은 버저닝을 안 하는 것

이라고 발표했다.

3. REST API란 무엇인가?

사람들이 알고있던 REST와 Roy T.Fielding이 생각하는 REST가 왜 차이가 날까?
REST API는 말그대로 REST아키텍쳐 스타일을 따르는 API이다.
REST는 분산 하이퍼미디어 시스템(예: 웹)을 위한 아키텍쳐 스타일이다.
이것은 제약조건의 집합이며 제약조건을 모두 지켜야 REST를 따른다고 할 수 있다.

1) REST를 구성하는 아키텍쳐 스타일

  • client-server
    • client와 Server의 역할이 명확하게 구분되어 의존성을 낮추어야한다.
  • stateless
    • server는 client의 상태정보를 계속 가지고있을 필요가 없다.
    • server는 오는 요청에 대한 응답만 하면 된다.
  • cache
    • 캐시사용이 가능해야한다.
  • uniform interface
    • 통일된 인터페이스
  • layered system
  • code-on-demand (optional)
    • 서버에서 코드를 클라로 보내서 실행할 수 있어야한다 -> 자바스크립트

uniform interface를 제외한 스타일들은 HTTP API를 사용하기만 해도 대체로 만족을 잘 하게된다. 하지만 uniform interface만은 잘 지켜지지 않는다.
uniform interface의 제약조건을 살펴보자.

2) uniform interface의 제약조건

  • identification of resources
    • 리소스가 uri로 식별되면 된다.
  • manipulation of resources through representations
    • representation전송을 통해 리소스를 조작해야한다.
    • 리소스를 만들거나 업데이트하거나 삭제하거나 할 때 메세지에 표현을 담아 달성한다.
  • self-descriptive messages
    • 메시지는 스스로를 설명해야한다 는 의미이다.
  • hypermedia as the engine of application state (HATEOAS)
    • 애플리케이션의 상태가 하이퍼링크를 이용해 전이되어야한다는 의미

REST API라고 알려져있는 거의 모든 것들이 self-descriptive messages와 HATEOAS 두가지는 지키지 못하고있다.
하나씩 살펴보자면

self-descriptive messages

GET/HTTP/1.1

이 HTTP 요청 메시지는 목적지가 빠져있어서 self-descriptive하지 못함

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

목적지를 추가하면 self-descriptive 만족

HTTP/1.1 200 OK
[ { "op": "remove", "path": "/a/b/c" } ]

어떤 문법으로 작성되어있는지,
op가 뭔지 path가 뭔지 모르기 때문에 self-descriptive불만족

HTTP/1.1 200 OK
Content-Type: application/json-patch+json
[ { "op": "remove", "path": "/a/b/c" } ]

self-descriptive 만족
이 요청 메시지의 내용만으로 모든것이 이해 되어야한다.

hypermedia as the engine of application state (HATEOAS)

애플리케이션의 상태가 하이퍼링크를 이용해 전이되어야한다는 의미이다.

  • 애플리케이션 상태의 전이
    • 이는 해당 페이지에 있는 하이퍼링크를 따라서 전이하기 때문에 HATEOAS를 만족한다.
HTTP/1.1 200 OK
Content-Type: text/html

<html>
<head></head>
<body><a href="/test">test</a></body>
</html>

a태그를 통해 하이퍼링크를 통해 그다음 상태로 전이가 가능

HTTP/1.1 200 OK
Content-Type: application/json
Link: </articles/1>; rel="previous", </articles/3>; rel="next";
{
    "title": "The second article"
    "contents" : "blah blah ..."
}

한 게시물을 제이슨으로 표현했다.
</articles/1>; rel="previous", </articles/3>; rel="next";
을 통해 uri 순서를 정보로 표현을 해 주었다.
이를통해 HATEOAS를 만족한다.

왜 Uniform interface를 만족해야하나?

독립적 진화를 하기 위해서 반드시 uniform interface는 만족 되어야 한다. 서버와 클라이언트가 각각 독립적으로 진화하고 이는 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없게된다. 이것이 REST를 만들게 된 계기이다. uniform interface가 만족되지 않으면 REST라 할 수 없는것이다.
그렇다면 self-descriptive와 hypermedia as the engine of application state가 독립적 진화에 어떻게 도움이 될까?

  • self-descriptive
    • 확장 가능한 커뮤니케이션이다.
    • 서버나 클라이언트가 변경되더라도 오고가는 메시지는 언제나 self-descriptive하므로 언제나 해석이 가능하다.
  • hypermedia as the engine of application state
    • 애플리케이션 상태 전이의 late binding이다.
    • 링크들은 동적으로 변경될 수 있다.

4. Web과 REST

REST는 웹의 독립적 진화에 지속적인 영향을 주었다.

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

이는 현재

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

로서 웹은 독립적으로 진화하고있다.

웹은 W3C Working groups, IETF Working groups, 웹브라우저, 서버 개발자들이 노력하여 HTML5 첫 초안에서 권고안 나오는데까지 6년, HTTP/1.1 명세 개정판 작업하는데 7년이 걸렸다. 왜이렇게 걸렸느냐면 상호운용성(interoperability)을 깨면 안되기 때문이다.

상호운용성(interoperability)에 대한 집착

  • Referer 오타지만 안 고침 (이미 따르고 있는 것이 많아서)
  • charset 잘못 지은 이름이지만 안 고침 (같은이유)
  • HTTP 상태 코드 416 포기함 (많은 애플리케이션이 그걸 따르고있어서)
  • HTTP/0.9 아직도 지원함

1) REST는 성공했는가?

REST는 웹의 독립적 진화를 위해 만들어졌다
웹은 독립적으로 진화하고있기 때문에 성공적이라 할 수 있다.

Yes

2) REST API는 성공했는가?

REST API는 REST 아키텍쳐 스타일을 따라야한다. 하지만 오늘날 스스로 REST API라고 하는 API들의 대부분이 REST 아키텍쳐 스타일을 따르지 않는다.

No

그렇다면 REST API도 저 제약조건을을 다 지켜야 하는건가?
Roy T.Fielding는 명시적으로 REST API는 self-descriptive한 메시지의 uniform interface를 지켜야한다고 말했다. 하지만 시스템 전체를 통제할 수 있다고 생각하거나 진화에 관심이 없다면 REST에 대해 따지느라 시간을 낭비하지 말라고 말했다.

5. 정리

오늘날 대부분의 REST API는 사실 REST를 따르지 않고 있다. REST의 제약조건 중 특히 self-descriptive와 hypermedia as the engine of application state를 잘 만족하지 못한다.
REST는 긴 시간에 걸쳐 진화하는 웹 애플리케이션을 위한 것이다. REST를 따를 것인지 API를 설계하는 이들이 스스로 판단하여 결정해야한다.
REST를 따르겠다면 self-descriptive와 hypermedia as the engine of application state를 만족시켜야한다

  • self-descriptive
    • custom media type이나 profile link relation등으로 만족가능.
  • hypermedia as the engine of application state
    • HTTP 헤더나 본문에 링크를 담아 만족시킬 수 있다.
      REST를 따르지 않겠다면 REST를 만족하지 않는 REST API를 뭐라고 부를지 결정해야 할 것이다.
  • HTTP API라고 부를 수도 있고
  • 그냥 이대로 REST API라고 부를 수도 있다. (Microsoft가 그러고있다.)

6. REST API가 무엇인지 묻는다면?

  • Web 애플리케이션 환경을 오랫동안 독립적으로 발전시키기 위해 등장한 REST 표준을 지킨 API를 말한다.
  • RESTful을 준수하기 위해서는 Stateless, Client-Servier, Uniform Interface 등의 조건을 만족해야한다.
  • Uniform Interface의 조건 중 Self-descriptiveness와 HATEOAS를 만족하는 것이 가장 어렵다.
    라고 말할 수 있겠다.
profile
왱구
늦깎이 애아빠 개발지망생
이전 포스트

싱글 서버 도커의 한계 -> 쿠버네티스

다음 포스트

디스코드(Discord)의 파일업로드는 왜 글자가 깨질까?

0개의 댓글