REST 하다는 것

 

백엔드 개발자가 가장 많이 다루는 것은 REST API 이다.

그러므로, REST API에 대해서 심도있게 학습할 필요가 있다.

 

기본기를 탄탄하게 갖춘 백엔드 개발자가 되기 위한 가장 기본적인 필수 요소이다.

 

 

API는 Client와 Server 사이의 인터페이스이다.
API는 다른 SW 시스템과 통신하기 위해 따르는 규칙을 정의한다.

REST 아키텍처 스타일을 따르는 API를 REST API 라고 하며,
해당 REST 아키텍처를 구현하는 웹 서비스를 RESTful 웹 서비스 라고 한다.

서버의 API가 HTTP를 준수하여 잘 설계되어 있다면 RESTful 하게 설계되었다고 볼 수 있다.

 

RESTful하게 잘 짜여있는 오픈소스들의 API를 참고하는게 가장 좋음.

위에 내용은 정말 얉은 내용이고, 아래 references 강의를 보며 정리한 내용을 살펴보자.

---

REST는

분산 하이퍼미디어 시스템(예: 웹)을 위한 아키텍쳐 스타일이다.

 

아키텍쳐 스타일은 

제약조건의 집합이다.

 

즉, 이 제약조건들을 모두 지켜야 REST를 따른다라는 말이 성립이 된다. 

REST는 여러가지의 아키텍쳐 스타일로 이루어져있다.

 

REST를 구성하는 스타일

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

대체로 HTTP만 잘 따라도 대부분 지킬 수 있다.

그러나, uniform interface를 잘 지키지 못한다.

 

 

Uniform Interface의 제약조건

• identification of resources (리소스가 uri로 식별되면 된다)
• manipulation of resources through representations (representations 전송을 통해서 리소스를 조작해야 한다.)
• self-descriptive messages
• hypermedia as the engine of application state (HATEOAS)

아래 두 제약 조건이 문제이다.

 

 

1. self-descriptive messages

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

즉, 메시지의 내용으로 온전히 해석이 가능해야 한다.

 

예시1)

GET / HTTP/1.1
이 HTTP 요청 메시지는 뭔가 빠져있어서 self-descriptive 하지 못하다.

목적지가 빠져있다.

GET / HTTP/1.1
Host : www.example.org
위와 같이 목적지를 추가하면 이제 self-descriptive 하다.

 

예시2)

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

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

위 메시지는 Content-Type : application/json 가 빠지면 self-descriptive 하지 못하다.

왜냐하면, 다음 응답 메시지를 받은 클라이언트는
이것이 어떤 문법으로 작성된 것인지 알 수 없으므로 해석이 불가하기 때문이다.

또한, 이것도 완벽하게  self-descriptive 하지 못하다.
op와 path가 어떤 데이터를 의미하는지 알 수 없다.


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

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

json-patch+json 라는 미디어 타입으로 정의되어 있는 메시지 이다.
json-patch+json에 대한 명세를 찾아 이해하고 해당 메시지를 해석하면 메시지의 의미를 명확하게 이해할 수 있다.

 

 

 

 

 

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

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

 

 

 

 

 

 

왜 Uniform Interface가 필요한가?

 

독립적 진화

• 서버와 클라이언트가 각각 독립적으로 진화한다.
• 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다. → 독립적인 진화
• 이 독립적인 진화야 말로 REST API를 만들게 된 계기이다. 

 

이러한 독립적인 진화를 달성하기 위해서는 Uniform Interface가 반드시 만족이 되어야 하고,

그렇기에, Uniform Interface를 만족하지 못하면 REST 라고 칭할 수 없다.

 

 

 

 

 

 

 

 

 

 

해당 내용은 해당 글의 맨 아래의 youtube 링크에 내용을 요약하였습니다.

---

References:

 

HTTP response 코드를 정리한 공식 문서 :

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

 

내일배움캠프를 하며 튜터님께서 추천해주신 강의

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