이 글은 What is REST? 를 번역 하였으며, 부족한 부분은 일부 내용을 추가하였습니다.
Roy Fielding 이라는 사람이 2000년에 논문에서 REST를 발표했다.
REST는 REpresentational State Transfer의 약어이자 광범위한 하이퍼미디어 시스템을 위한 아케텍처 스타일이다.
일반 텍스트와 달리 문장이나 단어 등이 링크를 통해 서로 연결된 네트워크 처럼 구성된 문서를 hypertext 라고 하는데 hypertext를 확장한 개념이 hypermedia 입니다. 하이퍼미디어(hypermedia)는 기존 hypertext에서 그래픽, 오디오, 비디오 등등을 포함시킨 개념입니다.
다른 아키텍처 스타일들과 마찬가지로, REST는 REST 만의 가이드라인 원칙이 있다.
서비스 인터페이스가 REST 가이드라인 원칙을 잘 따르는 경우 RETSful 하다고 할 수 있다.
REST 아키텍처 스타일을 준수한 Web API를 REST API 라고 한다.
1. REST 가이드 원칙
RESTful 아키텍처의 6가지 가이드 원칙은 다음과 같다.
1.1. Uniform Interface
컴포넌트 인터페이스에 일반원칙을 적용하여, 전반적인 시스템을 단순하게 할 수 있고 상호작용의 가시성을 향상시킬 수 있다.
여러 아키텍처적인 제약들은 uniform interface를 달성하고 컴포넌트의 동작을 안내하는데 도움이 된다
다음 4개의 제약들이 충족되면 uniform REST interface라고 할 수 있다
- Identification of resources
- 인터페이스는 클라이언트와 서버 사이의 상호작용에 연관된 각각의 자원을 개별적으로 식별해야한다.
- Manipulation of resources through representations
- 리소스는 서버 응답에 동일한 표현을 가져야 한다.
- API를 사용하는 클라이언트는 서버의 자원 상태를 수정하기 위해 표현을 사용해야 한다
- Self-descriptive messages
- 리소스 표현은 메시지를 처리하는 방법을 설명할 수 있는 충분한 정보를 전달해야 한다.
- 클라이언트가 리소스에 대해 수행할 수 있는 추가 작업에 대한 정보를 제공해야 한다.
RESTful API 에서의 특징
어떤 형식의 데이터인지(JSON, XML 등)와 그 구조가 명확하게 드러나야 한다.
적절한 상태코드를 사용해야 한다.
표준화된 헤더를 사용해야 한다.
링크와 하이퍼미디어를 사용한다.
- Hypermedia as the engine of application state(HATEOAS)
- 클라이언트는 애플리케이션의 초기 URI만 가지고 있어야 한다.
- 클라이언트 애플리케이션은 하이퍼링크를 사용하여 다른 모든 리소스와 상호 작용을 동적으로 수행해야 한다.
1.2. Client-Server
클라이언트-서버 설계 패턴은 클라이언트와 서버 컴포넌트들이 독립적으로 발전할 수 있도록 해준다.
유저 인터페이스에 관련된것들(클라이언트)을 데이터 저장에 관련된것들(서버)을 분리하여, 여러 플랫폼에서 사용자 인터페이스의 이식성을 향상시키고 서버 컴포넌트를 단순화하여 확장성을 향상시킨다.
we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components.
여기서 "multiple platform" 이라는 말이 나오는데 이 뜻은 서로 다른 하드웨어에서 같은 소프트웨어가 동작하는 것을 뜻한다. 이러한 말을 한것은 클라이언트의 다양한 환경(예 chrome, firefox 등등) 에서도 user interface가 동작하도록 하는것에 더 집중할 수 있다는 의미인것으로 추측된다
클라이언트와 서버가 서로 진화하는 동안, 클라이언트와 서버 사이에 인터페이스가 충돌되지 않도록 해야한다.
1.3. Stateless
클라이언트에서 서버로 요청은 서버측에서 그 요청을 완료하고 이해하는데 필요한 모든 정보를 포함해야 한다
서버는 이전 요청의 어떠한 문맥정보도 가질 수 없다.
이러한 이유로 클라이언트 어플리케이션은 세션 상태를 유지해야 한다.
1.4. Cacheable
캐시가능 여부에 대한 제약은 서버측의 응답이 암시적 또는 명시적으로 캐시가능 불가능 상태를 나타내는 것으로 표현한다.
만약 응답이 캐시가능 하다면, 클라이언트 애플리케이션은 구체적인 기간동안 동일한 요청에 대해 응답 데이터를 재사용할 권한을 얻는다.
1.5. Layered System
layered system 스타일은 아키텍처가 컴포넌트 행위를 제한하여 hierarchical layers로 구성되도록 한다.
예를들어, layered system에서는, 각 컴포넌트가 직접적으로 상호작용하는 계층 이외에는 볼수 없습니다.
위의 글만 봐서는 Layered System이 무엇인지 이해가 가질 않아서 이 글을 찾아 보았습니다.
요약하자면 클라이언트와 서버가 자원의 상태를 전달할 때에는 중간에 여러 서버들을 거치게 되는데
이 서버들은 각자 자신만의 역할을 하게 되어 직접적으로 관련있는 서버가 아니라면 서버들 끼리 무슨일을 하는지 모르게 됩니다.
이는 시스템의 확장성을 증가시키게 됩니다.
1.6. Code on Demand(Optional)
서버는 클라이언트에게 applets 또는 스크립트 그 자체를 응답하여, 클라이언트의 기능이 확장되도록 하게 해준다.
여기서 applets 이라는 것은 javascript 코드 이외에 어떤 응용 프로그램에 의해 즉시 실행 가능한 바이너리 코드를 말하는것으로 추측됩니다.
사용자의 컴퓨터에 다운로드된 코드는 클라이언트측에서 구현해야할 기능의 수를 줄이고 이는 클라이언트의 코드를 단순하게 만들어준다. 서버는 코드 그 자체의 형태로 기능을 제공하고 클라이언트는 그 코드를 실행하기만 하면 된다.
2. 리소스란?
REST에서 중요한 추상 정보는 "리소스" 이다. 우리가 명명할 수 있는 어떤 정보는 "리소스" 일 수 있다.
예를들어, REST 리소스는 도큐먼트, 이미지, 서비스, 다른 리소스들의 컬렉션 또는 실세계의 객체 일 수 있다.
특정 시기에 자원의 상태를 리소스 표현(resource representation)이라고 한다.
리소스 표현은 다음으로 구성된다.
- 데이터
- 데이터를 설명하는 메타데이터
- 클라이언트가 자원의 상태를 원하는 상태로 전환하는데 도움을 줄 수 있는 하이퍼미디어 링크
REST API는 내부적으로 연결된 리소스들의 조합으로 구성된다. 이러한 자원의 집합을 REST API의 리소스 모델 이라고 한다.
2.1. Resource Identifiers
REST는 서버와 클라이언트 컴포넌트들 사이의 상호작용에 연관된 각각의 리소스를 식별하기 위한 리소스 식별자를 사용한다.
2.2. Hypermedia
표현의 데이터 형식을 media type 이라고 한다. media type은 표현이 어떻게 가공될지를 정의하는 규격을 식별한다.
RESTful API는 하이퍼텍스트와 비슷하다. 모든 정보의 단위는 명시적(링크, id) 또는 암시적(media type 정의 와 표현 구조로 부터 얻어짐)으로 주소를 전달한다.
하이퍼텍스트(또는 하이퍼미디어)는 동시에 존재하는 자원의 표현을 의미하고 사용자가 선택권을 얻고 행위를 선택하도록 행위를 유발하는 정보 같은 것을 제어한다.
하이퍼 텍스트는 HTML(또는 XML 또는 JSON) 일필요가 없다는것을 기억하라. 기계들은 데이터 형식을 이해하고 관계 유형을 이해할 때 링크를 따른다.
Roy Fielding
2.3. Self-Descriptive
더 나아가, 리소스 표현은 자기 서술적이어야 한다: 클라이언트는 리소스가 직원인지 또는 기기인지 알 필요가 없다. 리소스와 연결된 media type에 따라 작동해야 한다.
그래서 실제로, 우리는 많은 사용자 지정 media type을 만든다 - 일반적으로 하나의 리소스와 연관된 하나의 media type
모든 media type은 기본 프로세싱 모델을 정의한다. 예를들어, HTML은 하이퍼텍스트에 대한 렌더링 프로세스와 각 요소에 대한 브라우저 동작을 정의한다.
media type 들은 일부 media type element 들이 process 모델을 정의한다는 사실을 제외하고는 리소스 메서드(GET/PUT/ 등등)에 관련이 없다
3. Resource Methods
REST와 관련된 또다른 중요한것은 리소스 메서드이다. 리소스 메서드는 특정 자원의 두가지 상태 사이에서 전환을 수행하는데 사용된다.
아주 많은 사람들이 리소스 메서드를 HTTP 메서드에 잘못 연관짓는다. Roy Fielding은 어느 메서드가 어느 조건에서 사용될지에 대한 어떤 권고도 언급한적이 없다. 그가 강조하는 것은 uniform interface 라는 것이다.
예를들어, 만약 우리가 애플리케이션 API가 리소스를 수정하는데 대부분 사람들이 HTTP PUT을 권고 하더라도 HTTP POST를 리소스를 수정하는데 사용한다면. 여전히 그 애플리케이션 인터페이스는 RESTful 하다고 할 수 있다.
리소스 상태를 전환하는데 필요한 모든 것은 리소스 표현의 일부가 되는 것이 이상적이다.
우리는 초기 URI와 의도된 대상 사용자가 이해할 수 있는 표준화된 미디어 유형들을 제외한 사전 지식 없이 REST API에 진입해야 한다.
이후로, 모든 애플리케이션 상태 변환들은 서버가 제공하는 선택지를 수신된 표현에서 클라이언트가 선택하거나 사용자가 해당 표현을 조작함으로써 이루어져야 합니다.
이러한 상태 변환들은 클라이언트의 media type과 리소스 통신 매커니즘에 대한 지식에 의해 결정되거나 제한될 수 있으며, 이러한 지식은 필요에 따라 실시간으로 개선될 수 있습니다(예, code on demand). 여기서 실패는 외부 정보가 하이퍼텍스트 대신 상호작용을 주도하고 있음을 의미합니다.
4. Rest 와 HTTP는 동일하지 않다
많은 사람들은 REST와 HTTP를 비교하기를 선호한다. REST와 HTTP는 다르다.
REST 또한 웹을 더욱 간소화하고 표준화 하려는 의도도 있지만, Roy Fielding 은 REST 원칙을 좀 더 엄격하게 사용하기를 바란다. 이러한 Roy Fielding의 생각은 REST 와 웹을 비교하기 시작하는 계기가 되었다.
Roy Fielding은 논문에서 프로토콜 선호도나 HTTP 등 구현 방향에 대해서는 언급하지 않았다.
지금 까지, 우리는 REST의 6가지 가이드 원칙을 준수하고 있으며, 이러한 인터페이스를 RESTful 이라고 한다.
5. 요약
- 간단히 말해서, REST 아키텍처 스타일에서, 데이터와 기능은 리소스로 여겨지고 Uniform Resource Identifiers(URIs) 를 이용하여 접근된다.
- 리소스는 일련의 단순하고 잘 정의된 작업을 사용하여 처리된다. 리소스들은 클라이언트가 HTML, XML, Plain text, PDF, JPEG, Json과 같은 다양한 형태로 콘텐츠에 접근할 수 있도록 잘 분리되어야 한다.
- 클라이언트와 서버는 표준화된 인터페이스와 프로토콜을 이용하여 자원의 표현들을 공유한다. 일반적으로 HTTP는 자주 사용되는 프로토콜이지만 REST는 HTTP를 강제하지 않는다.
- 리소스에 대한 메타데이터를 사용하여 캐싱을 제어하고, 전송 오류를 탐지하고, 적절한 표현 형식을 협상하고 인증 또는 접근 제어를 수행할 수 있다.
- 가장 중요한 것은 서버와의 모든 상호작용이 무상태여야 한다.
이러한 모든 원칙들은 RESTful 어플리케이션을 간단하고 가볍고 빠르게 한다.
