나는 지금까지 Rest api에 대한 이해를 완전히 잘 못하고 있었다. 그저 uri를 통해 HTTP의 메서드를 사용하여 데이터들을 컨트롤 하는 걸로 이해를 하고 있었다.

https://www.youtube.com/watch?v=RP_f5dMoHFc&list=WL&index=16&t=1008s

위의 영상을 보고 Rest Api의 내용을 다시 정리해 보려고 한다.

Rest API

REpresentational State Transfer

a way of providing interoperability between computer systems on the Internet- 위키백과
(컴퓨터 시스템 사이에 상호 운영성을 제공하는 시스템 중에 하나)

API - Application Programming Interface
프로그래밍 내부에 대해서 몰라도 API만 잘 알고 있다면 기능을 이용할 수 있다.

Rest API의 제약조건들

1. client-server

   • User Interface 와 서버 내부의 작업들을 분리함으로 이식성 향상
   • 클라이언트와 서버가 서로 의존하지 않음
   • 클라이언트는 서버의 리소스 URI만 알고 있음 된다.

2. Stateless

   • 클라이언트에서 서버로의 요청에는 필요한 모든 정보 포함
   • 서버에서의 클라이언트 정보 유지를 하면 안된다.

3. Cacheable

   • 요청에 대한 응답 내의 데이터에 해당 요청은 캐시가 가능한지 아닌지 명시
   • cache-control 헤더를 통해 캐시 여부 명시

4. Uniform Interface

   • 전체적인 시스템 아키텍처를 파악할 수 있도록 약속된 Interface
     (밑에서 더 설명해 보겠다.)

5. Layered System

   • 계층화된 시스템 아키텍처를 사용

6. Code on demand (optinal)

   • 서버가 네트워크를 통해 클라이언트에 전달한 프로그램들은 그 자체로 실행
     가능 해야 함

현재 많은 Rest API들이 나머지 규칙은 잘 지키는데 uniform Interface는 잘 만족하지 못한다고 한다.

Uniform Interface

1. identification of resources

   리소스들의 식별을 할 수 있어야 한다는 의미다. uri를 통해서 식별을 한다.
   ex) /posts, /post
   여기서 리소스란 데이터들을 의미를 한다.
   

2. manipulation of resources through representations

   이 부분은 어떠한 행위를 할 때는 POST,GET,PETCH,PUT 등과 같은 HTTP의 메서드를 사용을 해서 컨트롤을 한다는 뜻이다.

3. Self-descriptive message

   서버나 클라이언트가 변경되더라도 오가가는 메세지는 언제나 해석이 가능해야 한다.

4. hypermedia as the engine of application state (HATEOAS)

   클라이언트가 서버와 동적인 상호작용이 가능하도록 하는 것 => 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다.

대부분의 rest api는 1,2번은 잘 지키지만 3,4는 잘 지켜지지 않는다.

uniform interface가 필요한가?

독립적 진화

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

오고가는 메세지가 self-descriptive 하게 되면 서버나 클라이언트가 변경되더라도 언제나 해석이 가능하다.

또한 서버가 링크를 동적으로 변경해도 HATEOAS 하게 되면 클라이언트는 신경을 쓰지 않아도 된다.

웹과의 비교

json의 키 value가 어떤건지 모른다 => 불완전

1. HTML 부터 살펴보자
   

   • 응답 메세지의 content-Type을 보고 media type이 text/html임을 암
     
     
   • HTTP 명세에 media type은 IANA에 등록되있다고 하므로 IANA에서 text/html의 설명을 찾는다.
     
     
   • 명세를 따라가면 모든 태그의 해석 방법이 나와 있다.
     => 따라서 메세지 해석이 가능하다.
     
     
   • a 태그를 이용해 다음 상태로 전이될 수 있다. => HATEOAS 만족

2. JSON
   
   • 위의 과정과 비슷하지만 json 내에서 id가 무엇을 의미하고 title이 무엇을 의미하는 지 알 수 없다. => Self-descriptive FAIL
     
     
   • 다음 상태로 전이할 링크가 없다. => HATEOAS FAIL

Self-descriptive을 만족시킬려면 custom media type이나 profile link relation(위의 예시)등으로 만족시킬 수 있다.
HATEOAS는 HTTP 헤더나 본문(위의 예시)(에 링크를 담아 만족시킬 수 있다.
(유튜브를 참고해 보기 바란다.)

정리

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

2. 특히 Self-descriptive와 HATEOAS를 만족하지 못한다.

3. REST를 따르겠다면 Self-descriptive와 HATEOAS를 만족시켜야 한다.

4. REST를 따르지 않겠다면 뭐라고 부를지 결정해야 할 것이다.

   • HTTP API라고 부를 수도 있고
   • 그냥 이대로 REST API라고 부를 수도 있다. (만든 사람이 싫어함)