REST에 대한 정리글 [로이 필딩 논문을 훑어본 뒤...]

REST ?

The Representational State Transfer (REST) style is an abstraction of the architecturalelements within a distributed hypermedia system.

 

로이 필딩의 논문을 읽기 전까진 나도 긴가민가했다.

우선 REST는 API 설계에 대한 지침이라기보단 아키텍쳐 스타일에 대한 지침이었다.

---

 

REST를 만족하기 위한 제약사항

---

1. Client-Server

 

단순히 클라이언트-서버 통신 구조를 만족시키라는게 아니다.

클라이언트와 서버 간의 느슨한 결합이 핵심이다.

클라이언트와 서버가 독립적으로 진화할 수 있어야 함을 말하는 것.

 

2. Stateless

 

1번과도 관계가 있다. 서버와 클라이언트의 느슨한 결합을 위해서는 상태가 없어야 한다.

클라이언트는 서버에 요청할 때, 필요한 모든 데이터를 담아 요청을 보내야 한다.

 

그리고 세션이 필요하다면 클라이언트 측 세션을 이용해라.

(이 부분은 좀 새로웠다. 세션은 당연히 서버에 있는거 아닌가? 라고 생각했었는데)

 

3. Cache

 

2번에서 느슨한 결합을 위해 모든 요청에 필요한 데이터를 담아야한다고 했다.

이는 때때로 중복인 데이터를 반복적으로 보냄으로서 네트워크 성능 문제를 야기할 수 있다.

그렇기 때문에 캐시가 필요하다는것이다.

요청에 대한 응답은 캐시될 수 있는지, 없는지 명시해야 한다.

 

4. Uniform interface

 

클라이언트, 서버와 같은 컴포넌트 간 대화에 하나의 표준 인터페이스가 있어야 한다는 것.

Uniform interface를 구현하기 위해 4가지가 필요하다고 한다.

 

4.1 identification of resources (리소스의 식별)

4.2 manipulation if resources through representations (표현 계층을 통한 리소스 조작)

4.3 self-discriptive messages (자기 표현적인 메세지)

4.4 hypermedia as the engine of application state(HATEOAS) (애플리케이션 상태 전이 엔진으로서의 하이퍼미디어)

 

대부분 REST API에 대한 개념들은 여기서 파생된 것 같다.

 

조금 생소한건 4.2와 4.4다.

4.2의 경우를 웹에 빗대어 말하자면, 응답의 내용을 이용해 리소스 조작이 가능해야 한다는 걸 의미한다.

이를 위해서 응답에 리소스를 컨트롤하기 위한 데이터를 추가해야 한다.

4.4는 4.2를 충족시키기 위해 웹처럼 링크를 이용한다.

 

4.1~4.4 내용을 모두 종합하면,

리소스를 식별가능하도록 인터페이스(URL)를 구성하고, 링크를 이용해 클라이언트 측에서 리소스 조작이 가능하도록 한다. 그리고 응답이 최대한 자신을 표현할 수 있도록 구성하자.

이를 모두 만족시키면 응답 자체가 하나의 문서가 된다.

 

 

5. Layered System

 

아키텍쳐 측면의 이야기. 각 컴포넌트 간 직접적인 결합을 막기 위해 Layered System을 구축하라는 말이다.

 

예를 들자면, 클라이언트와 서비스들 간의 직접적인 연결을 막기 위해 중간에 게이트 웨이를 두거나, 프록시 서버 따위의 것들을 두는 것을 말하는 듯하다.