REST API

- 이 글은 "그런 REST API로 괜찮은가"와 추가적인 자료를 보고 작성자 스스로 이해를 위해 남기는 글입니다.

https://www.youtube.com/watch?v=RP_f5dMoHFc&t=701s

 

REST란?

분산 하이퍼미디어 시스템을 위한 아키텍쳐 스타일

HTTP에서 필요한 자원에 접근할 때 웹의 장점을 최대한 활용하기 위한 아키텍쳐로

자원의이름(표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미합니다.

 

자원 : 해당 소프트웨어가 관리하는 모든 것

상태 전달 :  데이터를 요청하는 시점의 '상태'(데이터를 언제 요청하는 지에 따라 값이 변화할 수 있기 때문에 상태라는 단어를 쓴 것으로 보인다.)를 전달

 

REST API란?

REST  아키텍쳐 스타일(제약조건의 집합)를 따르는 API

 

REST를 구성하는 스타일

1) Client-server 

2) stateless

3) cache

4) layered system

5) code-on-demand(optional)

6) uniform interface

 

개발자들의 REST API가 못만족 시키는 규칙 

 

 

1) self-descriptive message(스스로 메세지를 설명하다.)

HTML의 명세를 보면 태그등에 대한 모든 설명이 정의되어있기 때문에 self-descriptive message( 메시지의 의미를 해석할 수  있다)가능합니다.

1. Content-Type을 보고 media type을 확인 가능
2. HTTP 명세에 따라 media type은 IANA에 등록되어있다고 하므로 설명을 찾는다.
3. IANA에 따라 명세 링크를 구했으므로 링크로 들어가 명세를 해석한다
4. 명세 모든 태그 해석방법이 구체적으로 나와있어 문서를 해석할 수 있다.

2) Josn은 문법 해석은 가능하지만, 의미를 해석하려면 별도로 문서가 필요하기 때문에 self-descriptive message (의미를 해석하지 못한다.)불가능합니다.

     1.Content-Type을 보고 media type을 확인 가능

     2.HTTP 명세에 따라 media type은 IANA에 등록되어있다고 하므로 설명을 찾는다.

     3.IANA에 따라 명세 링크를 구했으므로 링크로 들어가 명세를 해석한다

     4.명세에 문서를 파싱 방법이 명시되어 파싱을 성공하지만 값들이 무엇을 의미하는 지를 알 방법이 없다

 

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

 

4) HTML

a 태그를 이용해 표현된 링크를 통해 다음 상태로 전이될 수 있으므로 HATEOAS를 만족한다.(하이퍼 링크를 클릭시 원하는 곳으로감)

 

5)Josn

링크가 없기 때문에 다음 상태로 전이할 수 없습니다.

 

해결방법

1. self-descriptive message

   미디어 타입에 값들의 의미를 정의하고 IANA에 미디어 타입을 등록합니다.

   (이 때 만든 문서를 미디어 타입의 명세로 등록)

 

   단점 : 매번 media type을 정의

 

2. Profile 

   값들의 의미를 정의한 명세를 작성한 뒤 Link 헤더에 해당 명세를 링크합니다.    

 

   단점  - 클리아이언트가 Link 헤더와 profile을 이해해야합니다.

           - Conetent negotiation을 할 수 없다.

3. HETEOAS

   -data에 다양한 방법으로 하이퍼링크를 표현합니다.

    단점 : 링크를 표현하는 방법을 직접 정의해야합니다.

   -Link,Location 등의 헤더로 링크를 표현합니다.