그런 REST API로 괜찮은가

김종완·2022년 6월 25일
0

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

REST의 약자

REpresentational -> 표현
State -> 상태
Transfer -> 전송

자원(RESOURCE)의 표현에 의한 상태(정보) 전달
리소스를 URL에 표현하여 주고받을 정보에 대해 어느정도 예측할 수 있다.

REST

a way of providing interoperability between computer systems on the Internet

  • 컴퓨터 시스템간에 상호운용성을 제공
  • 분산 하이퍼미디어 시스템(예: 웹)을 위한 아키텍쳐 스타일

REST 탄생당시 경쟁자였던 SOAP

SOAP

  • 복잡하다
  • 규칙 많음
  • 어렵다

REST

  • 단순하다
  • 규칙 적음
  • 쉽다

이러한 특성 차이로 인해서 REST가 살아남고 SOAP는 경쟁에서 밀려나게 되었다.

Microsoft REST API Guidelines (2016)

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

REST API란

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

REST를 구성하는 아키텍처 스타일

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

code-on-demand의 의미는 서버에서 코드를 클라이언트에 보내서 실행할 수 있어야 한다. ex) javascript

Uniform Interface의 제약조건

  • identification of resources
  • manipulation of resources through representations
  • self-descriptive messages
    • 메시지가 스스로를 설명해야한다.
  • hypermedia as the engine of application state (HATEOAS)

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

왜 Uniform Interface 만족해야하는가?

for 독립적 진화

  • 서버와 클라이언트가 각각 독립적으로 진화한다.
  • 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
  • REST를 만들게 된 계기

    "How do I improve HTTP without breaking the web."
    웹을 망가트리지 않고 HTTP를 발전시키는 방법

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

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

  • Referer 오타지만 안 고침 고치게되면 기존에 Referer를 사용하던 곳은 사용 불가하게 됨
  • charset 잘못 지은 이름이지만 안 고침
  • HTTP 상태 코드 416 포기함(I'm a teapot)
  • HTTP/0.9 아직도 지원함 (크롬, 파이어폭스)

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

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

REST API는 잘 지켜지고 있는가?

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

An API that provides network-based access to resources via a uniform interface of self-descriptive messages containing hypertext to indicate potential state transitions might be part of an overall system that is a RESTful application
-- Roy T. Fielding

하이퍼텍스트를 포함한 self-sescriptive한 메시지의 uniform interface를 통해 리소스에 접근하는 API

정리

  • 오늘날 대부분의 "REST API"는 사실 REST를 따르지 않고 있다.

  • REST의 제약조건 중에서 특히 Self-descriptive와 HATEOAS를 잘 만족하지 못한다.

  • REST는 긴 시간에 걸쳐(수십년) 진화하는 웹 애플리케이션을 위한 것딩다.

  • REST를 따를 것인지는 API를 설계하는 이들이 스스로 판단하여 결정해야한다.

  • REST를 따르겠다면, self-descriptive와 HATEOAS를 만족시켜야한다.

    • self-descriptive는 custom media type이나 profile link relation 등으로 만족시킬 수 있다.
    • HATEOAS는 HTTP 헤더나 본문에 링크를 담아 만족시킬 수 있다.
  • REST를 따르지 않겠다면, "REST를 만족하지 않는 REST API"를 뭐라고 부를지 결정해야 할 것이다.

    • HTTP API라고 부를 수도 있고
    • 그냥 REST APIL라고도 부를 수 있다.
profile
개발에 재미를 느끼며 꾸준히 성장하는 개발자 김종완 입니다.

0개의 댓글