본문 바로가기

웹 프로그래밍/BackEnd

REST API(그런 REST API로 괜찮은가?)

오늘날 대부분 "REST API"라고 불리는 것들은 REST하지 않다!!

 

그럼 REST가 뭔데?

컴퓨터 시스템와 인터넷 사이에 상호 운용성을 제공하는 방법

=> 즉, 서로 독립적으로 발전이 가능한 형태를 말한다.

REST를 만든 로이필딩은 "웹을 망가뜨리지 않고 http기능을 추가하고 싶다"라는 생각으로 만들었다고 한다.

 

 

그러면 REST를 지키려면 어떻게 해야돼?

  1. Client-Server
  2. Stateless
  3. Cache
  4. Uniform Interface
  5. Layered System
  6. Code-on-Demand (optional)

를 만족 해야한다.

=> http만 잘 따라도 1,2,3,5는 지킬 수 있다.

=> 6은 서버에서 코드를 클라이언트로 보내 실행할 수 있어야 한다. 자바스크립트를 의미하고 필수는 아니다.

 

 

요즘 REST API라고 불리는 것들은 4번이 지켜지지 않는다.

그럼 Uniform Interface를 지키려면 어떻게 해야돼?

  1. Identification of resources
    • URI로 리소스 식별
  2. Manipulation of resources through representations
    • representation 전송을 통해서 리소스를 조작
  3. Self-descriptive messages
  4. Hypermedia as the engine of application state(HATEOAS)

이걸 지키면 된다.

그러나 3,4을 지키지 않고 있다.

 

 

3,4번 조건에 대해 알아보자
3. Self-descriptive messages

메세지는 스스로를 설명해야한다.

 

 

GET / HTTP/1.1

는 Self-descriptive messages를 만족할까?

이것만 봐서는 어디로 보내는지 알수 없다.

 

 

그럼 

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

는 만족할까?

이것만 봐서는 클라이언트가 어떤 문법으로 작성된지 모른다.

 

 

HTTP/1.1 200 OK
Content-Type: application/json

[ { "op": "remove", "path": "/a/b/c" } ]

그렇다면 타입을 넣어주면 만족할까? NO..

op, path가 무엇을 의미하는지 우리만 안다..!

 

 

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

이렇게 하면 만족된다.

json-patch+json이라는 미디어 타입으로 정의된 메시지이고, json-patch라는 명세를 찾아가서 이해한 다음, 이 메시지를 해석할 수 있다!!

 

 

이처럼 메세지만 보고 완전히 해석이 가능해야한다는 것이 Self-descriptive messages 조건이다.

 

그렇다면 Hypermedia as the engine of application state(HATEOAS)는 뭐지?

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

 

 

HTTP/1.1 200 OK 
Content-Type: text/html

<html>
  <head>
  </head>
  <body>
  	<a href="/test"> test </a>
  </body>
</html>
이런 식으로 a태그를 통해 하이퍼링크가 나와있고, 링크를 통해 다음상태로 전이되는 것을 말한다.

 

 

그렇다면 Json형식은 어떻게 만족할까?
HTTP/1.1 200 OK
Content-Type: application/json
Link: </articles/1>; rel="previous", </articles/3>; rel="next";

{
"title": "The second article",
"contents": "blah blah..."
}

위처럼 하면 Link라는 헤더를 통해 다른 리소스를 가리킬 수 있게 된다.

 

 

"다시 REST의 조건으로 돌아와서"

Uniform Interface가 왜 필요해?

- 독립적 진화를 하기위해

- 서버와 클라이언트 각각 독립적으로 진화

- 서버의 기능이 변경되어도 클라이언트를 업데이트 할 필요가 없어진다!

- REST의 목적이 독립적인 진화이기 때문에 Uniform Interface가 필수이다.

 

 

REST를 잘지키고 있는 사례는 바로 우리가 매일 접하는 웹이다.

생각해보자

웹페이지를 변경했을때 브라우저를 업데이트 안해도 된다.

반대로 브라우저를 업데이트해도 웹페이지를 변경하지 않아도 된다.

HTTP,HTML명세가 변경되어도 웹은 아무문제없이 동작한다.

 

 

그렇다면 왜 여러 API는 REST API라고 불리는 것일까?

=> 조건을 만족하지 않아 REST가 아니지만 그냥 REST API라고 부른다..!ㅎㅎ(하지만 로이 필딩이 매우 싫어한다..! -> 다른 이름을 써!!라고 한다.)

 

끝!

 

참고 영상 : https://tv.naver.com/v/2292653

반응형
SMALL