#2 : RESTful Architecture Style

REST를 구성하는 아키텍처 스타일을 모아보았다.

1. Client - Server

2. Stateless

3. Cache

4. Uniform Interface

5. Layered System

6. Code On Demand (이 녀석은 Optional)

 

잘 보면 HTTP API만 잘 지켜져도 다 만족할 수 있는 녀석들이다. 그러나 4번 Uniform Interface라는 녀석만이 지켜지기 어렵다. Uniform Interface의 4가지 제약조건이 있다.

1. Identification of resources
2. Manipulation of resources through representions
3. self descriptive messages
4. hypermedia as the engine of application state

이 중에서도 3번 항목과 4번 항목이 잘 지캬지지 않는다고 한다.

 

self descriptive messages의 예를 보자.

REST 에서는 self descriptive messages, 즉 메시지가 스스로 설명 하는 걸 이야기한다. - GET / HTTP/1.1 HTTP 통신하다 보면 상기 메시지를 많이 접할 수 있다. 상기 메시지에는 목적지를 알 수 없으므로 제대로 설명되어 있지 않기 때문에 지켜지지 않은 것이다. 이럴 땐 Host Header를 추가해서 잘 설명되어야 한다.

hypermedia as the engine of application state의 예를 보자.

hypermedia as the engine of application state, 즉 애플리케이션의 상태는 Hyperlink를 이용해서 전이 되어야한다. 이는 HATEOAS라고 읽기도 한다.   다시말해, 우리가 많이 알고있는 HTML로 이야기를하면 하이퍼링크를 통해 상태가 변경되어야한다는 말이다.

 

그래서 우리는 왜 Uniform Interface 제약조건을 지켜야 하는가?

  나도 서버 개발자이지만 "서버"라는 이 광범위한 것을 다 아는 것은 무리다. 서버가 있으면 당연히 클라이언트도 있을 것이고 이 두 녀석은 각각 독립적으로 버저닝이 되고 개발이 될 것이다. 또한 서버의 기능이 변경되어도 클라이언트는 업데이트할 필요가 없어야 한다. 반대로 클라이언트가 버전 업이 되거나 기능이 변경되어도 동일해야 한다. 그렇기 때문에 상기 예 처럼 꼭 지켜야하는 제약조건이 되는 것이다.

 

 

 

 

  호환성을 고려한다는건 정말... 너무 힘들다ㅠㅠ