[REST API]REST를 사용할 때 주의해야할 점

REST를 만든사람 : 로이필딩, 박사학위 논문 (https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)

REST API : REST 아키텍처를 따르는 시스템

구성요소

• Client-Server
• stateless
• cache
• uniform interface
• layered system
• code-on-demand (optional)

—> 대부분의 요소는 잘 지켜지고 있다. ( 브라우저 같은 곳에서 지원하기 때문 )

—> Uniform interface가 잘 지켜지는지는 되돌아볼 필요가 있다.

---

Uniform interface 제약조건

• identification of resources
• manipulation of resources thorough representations
• self-descriptive message
• HATEOS( hypermedia as the engine of application state)

Self-descriptive message

GET / HTTP/1.1

—> 이런 호출은 Self-descriptive message가 아니다. 왜냐하면 목적지가 없기때문

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

—> 이렇게 변경하면 Self-descriptive message가 된다.

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

—> 서버가 위와 같이 응답한다면 아래와 같이 바꾸어야 Self-descriptive message라고 할만하다.

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

—> json-patch의 명세를 보면 확인할 수 있다.
즉, Self-Descriptive message(자기 서술적 메시지)란 메시지 만으로 어떤 메시지 인지 알 수 있어야 한다.

HATEOAS

—> 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야한다. (페이지 변경 등)

HTTP/1.1 200 OK
Content-Type: application/json
Link: </articles/1>; rel=“previous”,
      </articles/3>; rel=“next”;
{
    “Title” : “The second article”,
    “content” : “Hello! Brother"
}

위와 같이 표현되어도 되며, 아래와 같이 Json에 포함시켜도 된다.

HTTP/1.1 200 OK
Content-Type: application/json
{
    “Title” : “The second article”,
    “content” : “Hello! Brother"
    href :
    {
        previous : /article/1
        next : article/3
    }
}

---

—> Uniform Interface가 필요한 이유

—> 서버와 클라이언트가 각각 독립적으로 진화하면, 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없게 하기 위해서

서버의 독립적 진화에 도움이 되는가 ?

• Self-descriptive
  • 서버나 클라이언트가 변경되더라도 오고가는 메시지는 언제나 self-descriptive하므로 언제나 해석이 가능
• HATEOAS
  • 어디서 어디로 전이가 가능한지 미리 결정되지 않는다. 어떤 상태로 전이가 완료되고 나서야 그 다음 전이 될 수 있는 상태가 결정된다. 링크가 동적으로 변경될 수 있음.

---

참고 : https://www.youtube.com/watch?v=RP_f5dMoHFc&t=1149s