REST / RESTful API

 

대부분의 현대 애플리케이션들은 위 그림처럼, 소위 프론트엔드라고 부르는 클라이언트와 백엔드라고 부르는 서버가 상호간 데이터를 주고 받는 형태의 아키텍쳐를 가지고 있습니다.

 

이렇게 서버와 클라이언트가 분리되는 구조의 가장 큰 특징 중 하나는 서버와 클라이언트가 독립적으로 진화할 수 있다는 것입니다. 독립적으로 진화한다는 뜻은 각각의 업데이트 내용이 서로에게 영향을 끼치지 않는 다는 것입니다. 즉, 서버의 기능이 변경되어도 클라이언트는 업데이트 할 필요가 없고 그 반대 역시 마찬가지 입니다.

 

가장 대표적인 예시는 웹(Web) 입니다. 웹 페이지가 변경되었다고 해서 웹 브라우저를 업데이트 할 필요도 없으며, 웹 브라우저가 업데이트 됐다고 해서 웹 페이지를 변경할 필요도 없습니다. HTTP 명세가 변경되거나, HTML 명세가 변경되어도 웹은 잘 동작합니다. 서버와 클라이언트가 서로에게 영향을 끼치지 않고 독립적으로 진화하기 때문입니다.

 

오늘 살펴볼 REST는 바로 이런 웹의 독립적 진화를 위한 분산 시스템 아키텍쳐라 스타일이라고 할 수 있습니다.

 

REpresentation State Transfer

---

REST는 2000년 HTTP의 주요 저자 중 한 사람인 로이 필딩에 의해 제안 되었습니다. 그는 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표 하였습니다. 이 REST를 통해 웹의 독립적 진화가 가능하게 되었고 웹기술이 지속적으로 발전할 수 있게 되었습니다.

 

그렇다면 REST는 어떤 방식으로 웹의 독립적 진화를 가능하게 하는 것일까요? 이것을 설명하기 위해 일단 아키텍쳐 스타일이란 단순하게 말하면 결국 여러 제약조건의 집합이라는 점을 이해 해야 합니다. 즉 REST 역시 이러한 제약조건의 집합이고 이러한 제약조건을 통해 웹의 독립적 진화를 가능하도록 만드는 것입니다.

 

REST 는 다음 여섯가지 제약 조건을 가지고 있습니다.

 

Client - Server

 

흔히 이야기하는 서버와 클라이언트의 관계를 의미합니다. 앞서 이야기 한 것 처럼 현대 애플리케이션 대부분이 서버-클라이언트 기반으로 만들어지고 사실상 이 구조를 벗어나는 것 자체가 힘든 일이기 때문에 자연스럽게 만족되는 제약조건이라고 할 수 있습니다. 중요한 것은 서로의 관심사를 잘 구분하고 각각의 로직이 독립적인 진화를 할 수 있도록 해야 한다는 것입니다.

 

Stateless

 

HTTP 는 Stateless 한  프로토콜입니다. 따라서 현재 상태에 대한 정보를 유지하지 않습니다. 그렇기 때문에 모든 요청은 각자 필요한 정보를 모두 담고 있어야 합니다. 요청 하나만 봐도 그 요청의 내용을 바로 알아볼 수 있어야 한다는 것입니다. 서버와 클라이언트가 완전히 독립되어 있기 때문에 REST 요청 하나 안에 필요한 모든 정보를 담고 있지 않으면 그 데이터를 해석할 수 없기 때문입니다.

 

Cache

 

HTTP 라는 이미 존재하는 프로토콜을 사용하기 때문에 웹에서 사용되는 기술인 캐시 역시 사용 가능합니다. 그렇기 때문에 모든 서버 응답은 캐시가 사용 가능한지 불가능한지를 알고 있어야 하며 캐시 사용을 고려한 설계가 필요합니다.

 

Uniform Interface

 

구성요소(서버, 클라이언트 등)간의 인터페이스가 균일해야 한다는 것을 의미합니다. 구체적으로 미디어 유형이나, 리소스 식별자 등을 구별하는 문법이 상호간 동일해야 한다는 뜻입니다. 서버와 클라이언트가 완전히 독립되어 서로의 상태나 특성을 알지 못하기 때문에 당연히 서로가 알 수 있는 문법으로 소통해야 하고 동일한 인터페이스를 사용한다면 당연히 더욱 효율적일 것입니다. 즉, 서로의 특성을 몰라도 쉽게 커뮤니케이션 할 수 있어야 각각 독립적으로 진화할 수 있는 유연한 시스템이 될 수 있다는 것입니다.

 

REST는 Uniform Interface 를 위해 네가지 제약사항을 제시하고 있습니다.

 

1. identification of resources

리소스를 식별하는 방법이 동일해야 합니다. 흔히 URI를 통해 리소스를 식별합니다.

 

2. manipulation of resources through representation

리소스 자체를 전송하는 것이 아닌 리소스의 표현을 전송한다는 뜻입니다. 서버에 있는 리소스가 아니라 현재 리소스의 상태를 반영하는 표현체를 전송함으로서 서버의 리소스 상태가 변해도 클라이언트에는 영향을 끼치지 않도록 합니다.

 

3. self-descriptive messages

요청이나 응답에는 스스로를 설명하는 정보를 포함하고 있어야 합니다. 따라서 수신자는 이 정보를 통해 메세지를 이해할 수 있습니다.

 

4. hypermedia as the engine of application state

애플리케이션의 상태는 하이퍼미디어에 의해 변경된다는 것입니다. 따라서 서버는 Hypermedia를 통해 다음 액션에 대한 선택지를 클라이언트에게 제공해야 합니다. HATETOAS의 목적은 (서버-클라이언트 간 의존성을 분리해야만 가능한) 독자적인 진화와 확장을 보조하는 것이며, hypermedia는 그 목적을 이루는 데 기여해야 합니다.

 

비록 위 조건들을 모두 엄격하게 만족하는 경우에만 REST라고 할 수 있겠지만 대부분의 경우 3번과 4번, 특히나 4번은 잘 지켜지지 않고 있습니다.

 

Layered System

 

클라이언트 혹은 서버 둘 다 미들웨어 구성을 추가할 수 있는 구조를 가지고 있어야 한다는 것입니다. 그러나 클라이언트에서는 서버에 어떤 미들웨어가 추가되었는지 알 필요가 없고 그 반대도 마찬가지여야 합니다. 중요한 것은 서버와 클라이언트의 커뮤니케이션이 일관성 있게 유지되는 것입니다.

 

Code On Demand (Optional)

 

서버는 클라이언트로 실행 가능한 프로그램을 전달할 수 있어야 합니다. 쉽게 JavaScript를 생각하시면 됩니다. 그러나 이 제약조건은 선택사항이며 필수적이지는 않습니다. 

 

RESTful API

---

REST 라고 불리는 위의 제약조건에 따른 API를 REST API 라고 합니다. 그러나 우리가 REST API 라고 부르는 것들이 사실은 REST 하지 않은 경우가 대부분입니다. 특히 self-descriptive messages와 hypermedia as the engine of application state 원칙을 지키는 것이 상당히 까다로운 편이기 때문에 이 두원칙을 지키지 못하는 경우가 많습니다.

 

물론 로이 필딩은 이런 API들을 REST 라고 불러선 안된다고 주장하지만 이미 많은 개발자들과 기업들은 REST 원칙을 모두 지키지 못한 API들을 REST API라고 부르고 있습니다.

 

그리고 이런 과정에서 퍼진 REST API 에 대한 가장 큰 오해는 REST 가 (좋은) URI 패턴과 GET, POST, PUT, DELETE 같은 HTTP method 의 조합으로 이루어져 있다고 생각하는 것입니다. 물론 이것은 REST 제약조건의 일부분을 만족시키는 방법이지만 REST 그 자체는 아닙니다.

 

참고자료

---

http://haah.kr/2017/05/22/rest-the-beginning/

REST - 긴 여정의 시작

https://linked2ev.github.io/devlog/2019/10/06/WEB-REST-is-the-independent-evolution-of-the-web/

[WEB] REST는 웹의 독립 된 진화

https://www.youtube.com/watch?v=RP_f5dMoHFc&t=2s