넓고 얕은 네트워크 지식

그런 REST API로 괜찮은가? 요약 정리

팡펑퐁 2023. 2. 16. 04:01
728x90
🚨 이 글은 그런 REST API로 괜찮은가?를 보고 정리한 영상이므로 두서가 없음.

어떻게 인터넷에서 정보를 공유할까에 대한 고민

정보를 하이버텍스트로 연결하자.

표현 형식 : HTML

식별자 : URI

전송 방법 : HTTP

 

Roy T Fielding이라는 사람이 기존의 웹을 망가뜨리지 않고 HTTP를 개선할 수 있을까를 고민하여 나온 해결책이 REST

 

API의 등장

세일즈포스에서 API를 공개(SOAP API)

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

4년 후에 플리커에서 API 공개(REST API)

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

REST의 승리

 

2016년에 REST API에 대한 가이드라인을 만든 마이크로소프트 사.

그런데,  정작 Roy T Fielding은 그건 REST API가 아니다, HTTP API라고 해야 한다라고 함

 

사람들 반응 : ? 그럼 REST API가 정확히 뭔데?

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

 

아키텍처 스타일 : 제약 조건의 집합을 의미하며 REST API는 이를 모두 따라야 함

 

REST를 구성하는 스타일

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

대부분 HTTP 제약 조건을 잘 지키면 REST 아키텍처 스타일을 잘 따르게 된다.

uniform interface 빼고..

 

Uniform Interface의 제약 조건

  • identification of resources
  • manipulation of resources through representations
  • self-descriptive messages
  • hypermedia as the engine of application state (HATEOAS, 헤이티오스)

 

self-descriptive message : 메시지는 스스로를 설명해야 한다.

  • 메시지 안에 메시지에 대한 설명이 들어가야 한다.
  • 메시지의 내용만을 가지고 메시지의 해석이 온전히 가능해야 한다.

 

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

  • 애플리케이션 상태의 전이를 만족해야 한다.
  • 메인 -> 글 목록 보기(GET /articles) -> 글쓰기(GET /new-form) -> 글저장(POST /articles) -> 생성된 글 보기(GER/articles/10) -> 글목록 보기(GET /articles)

 

왜 Uniform Interface가 필요한가?

독립적인 진화를 위해서

  • 서버와 클라이언트가 각각 독립적으로 진화한다.
  • 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
  • REST를 만들게 된 계기 : 웹을 망가뜨리지 않고 HTTP를 어떻게 개선할 수 있을까?

 

웹

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

 

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

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

 

그럼 REST는 성공했는가

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

 

그런데 REST API는?

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

 

REST는 단순하고 쉬운 줄 알았는데.. 어렵다

 

Fielding : 시스템 전체를 통제할 수 있다고 생각하거나, 진화에 관심이 없다면 REST에 대해 따지느라 시간 낭비하지 마라.

 

그럼 이제 어떻게 해야 할까?

  1. REST API를 구현하고 REST API라고 부른다.(도전)
  2. REST API 구현을 포기하고 HTTP API라고 부른다.
  3. 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

  • Media type의 정의하여 IANA에 등록 -> 메시지를 보는 사람이 해당 명세를 찾아가 해석 가능
  • Link 헤더에 profile relation을 링크하여  -> 메시지를 보는 사람이 해당 명세를 찾아가 해석 가능

 

HATEOAS

  • data에 하이퍼링크를 달아 정의한다.(하이퍼링크가 반드시 uri일 필요는 없다)
  • HTTP 헤더 중에 Link, Location 등의 헤더로 링크를 표현한다.

 

 

정리

  • 오늘날 대부분의 "REST API"는 사실 REST를 따르디 않고 있다.
  • REST의 제약조건 중에서 특히 Self-dexcriptive와 HATEOAS를 잘 만족하지 못한다.
  • REST는 긴 시간에 걸쳐 진화하는 웹 애플리케이션을 위한 것이다.
  • REST를 따를 것인지는 API를 설계하는 이들이 스스로 판단하여 결정해야 한다.
  • REST를 따르겠다면, Self-descriptive와 HATEOAS를 만족시켜야 한다.
    • Self-descriptice는 custom media type이나 profile link relation 등으로 만족시킬 수 있다.
    • HATEOAS는 HTTP 헤더나 본문에 링크를 담아 만족시킬 수 있다.

 

출처:

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

 

728x90