바쁜 개발자들을 위한 REST 논문 요약

REST란 무엇인가? REST는 Representational State Transfer의 줄임말로, 웹을 위한 네트워크 기반 아키텍처 스타일이다. REST는 Roy T. Fielding이 그의 박사학위 논문 “Architectural Styles and the Design of Network-based Software Architectures” 에서 처음 소개하였다.

그의 논문을 읽고 매우 간략히 요약해보았다. 논문의 모든 부분을 동등하게 요약하지는 않았고, REST가 무엇인가를 이해하는데 초점을 맞추어 차별적으로 요약하였다.

논문 요약

1장: Software Architecture

아키텍처 스타일(architectural style)이란, 그 스타일을 따르는 아키텍처가 지켜야 하는 제약조건들의 집합이다.

2장: Network-based Application Architectures

이 논문에서 다루는 아키텍처 스타일의 적용 범위는 네트워크 기반 애플리케이션(Network-based Application)으로 한정된다.

네트워크 기반 소프트웨어는 operation이 네트워크를 경유해서 일어난다는 사실을 사용자에게 감출 필요가 없다. 분산(distributed) 소프트웨어는 감추어야한다.

애플리케이션이기 때문에, OS나 네트워킹 소프트웨어 같은 것은 고려 대상에서 제외된다.

네트워크 기반 애플리케이션 아키텍처의 관심 사항은 다음과 같다.

성능
규모확장성(Scalability)
단순성
수정용이성(Modifiability)
가시성(Visibility)
이식성(Portability)
신뢰성(Reliability)

3장: Network-based Architectural Styles

이 장에서는 Pipe and Filter, Layered-Client-Cache-Stateless-Server, Code on Demand 를 비롯한 여러가지 네트워크 기반 아키텍처 스타일들을 소개한다.

4장: Designing the Web Architecture: Problems and Insights

이 장에서는 웹 아키텍처의 요구사항, 해결해야할 문제를 설명하고 이를 해결하기 위한 접근 방법을 제시한다.

5장: Representational State Transfer (REST)

4장에서 제시한 접근방법의 결과물로 웹을 위한 아키텍처 스타일 “REST”를 소개한다. REST는 3장에서 소개했던 네트워크 기반 아키텍처 스타일들 몇 가지와 추가로 Uniform Interface 스타일을 함께 결합한 하이브리드 스타일이다.

Client-Server – 클라이언트-서버 스타일은 사용자 인터페이스에 대한 관심(concern)을 데이터 저장에 대한 관심으로부터 분리함으로써 클라이언트의 이식성과 서버의 규모확장성을 개선한다.
Stateless – 클라이언트와 서버의 통신에는 상태가 없어야한다. 모든 요청은 필요한 모든 정보를 담고 있어야한다. 요청 하나만 봐도 바로 뭔지 알 수 있으므로 가시성이 개선되고, task 실패시 복원이 쉬우므로 신뢰성이 개선되며, 상태를 저장할 필요가 없으므로 규모확장성이 개선된다.
Cache – 캐시가 가능해야한다. 즉 모든 서버 응답은 캐시 가능한지 그렇지 아닌지 알 수 있어야한다. 호율, 규모확장성, 사용자 입장에서의 성능이 개선된다.
Uniform Interface – 구성요소(클라이언트, 서버 등) 사이의 인터페이스는 균일(uniform)해야한다. 인터페이스를 일반화함으로써, 전체 시스템 아키텍처가 단순해지고, 상호작용의 가시성이 개선되며, 구현과 서비스가 분리되므로 독립적인 진화가 가능해진다. 이 스타일은 다음의 네 제약조건으로 이루어진다: identification of resources, manipulation of resources through representation, self-descriptive messages, hypermedia as the engine of application state
Layered System – 계층(hierarchical layers)으로 구성이 가능해야하며, 각 레이어에 속한 구성요소는 인접하지 않은 레이어의 구성요소를 볼 수 없어야한다.
Code-On-Demand (Optional) – Code-On-Demand가 가능해야한다. 서버가 네트워크를 통해 클라이언트에 프로그램을 전달하면 그 프로그램이 클라이언트에서 실행될 수 있어야한다. (Java applet이나 Javascript 같은 것을 말함) 다만 이 제약조건은 필수는 아니다.

6장: Experience and Evaluation

REST 아키텍처 스타일은 URI, HTTP 등의 웹 표준에 반영되었다.

문제는 Uniform Interface (그리고 다음 포스팅 예고)

우리가 이 논문에서 가장 주목해야 할 부분은 바로, REST를 구성하는 스타일들 중 하나인 “Uniform Interface”다. 이 스타일에 따르면, REST API는 기본 URI와 미디어 타입의 정의만 알면 이용할 수 있어야한다.

예를 들어 Github API가 REST API라면, https://api.github.com 이라는 기본 URI와 application/json의 정의만 알면 API 문서 없이도 Github API 전체가 이용이 가능해야 한다는 말이 된다. 아마 가능하지 않을 것이다. 따라서 Github API는 REST API가 아니다. 아마 세상의 거의 모든 HTTP API가 REST API가 아닐 것이다.

Code-On-Demand를 제외한 모든 스타일을 다 따라야만 REST API이기 때문에, 자신의 API를 REST API라고 부르고 싶다면 이 Uniform Interface 스타일 역시 따라야한다.

과연 Uniform Interface 스타일을 따르는 것은 가능할까? 아니 그 이전에 따르기는 해야 하는 것일까? 그것에 대해서는 다음 포스팅에서 다룰 것이다.