REST란?(What is REST)

REST는 약어입니다.

for REpresentational State Transfer and an architectural style for distributed hypermedia systems.

로이 필딩 (Roy Fielding)은 2000 년 그의 유명한 논문에서 처음으로 그것을 발표했습니다.

다른 아키텍처 스타일과 마찬가지로 REST에는 기본 원칙과 제약 조건이 있습니다. 서비스 인터페이스를 RESTful이라고 해야 하는 경우 이러한 원칙을 충족해야 합니다.

A Web API (or Web Service) conforming to the REST architectural style is a REST API.

1. Guiding Principles of REST

RESTful 아키텍처의 6가지 기본 원칙 또는 제약 조건은 다음과 같습니다.

1.1. Uniform Interface

구성 요소 인터페이스에 일반성 원칙을 적용함으로써 전체 시스템 아키텍처를 단순화하고 상호 작용의 가시성을 향상시킬 수 있습니다.

여러 아키텍처 제약 조건은 균일한 인터페이스를 얻고 구성 요소의 동작을 안내하는 데 도움이 됩니다.

다음 네 가지 제약 조건은 균일한 REST 인터페이스를 달성할 수 있습니다.

• Identification of resources – 인터페이스는 클라이언트와 서버 간의 상호 작용과 관련된 각 리소스를 고유하게 식별해야 합니다.
• Manipulation of resources through representations – 리소스는 서버 응답에서 균일한 표현을 가져야 합니다. API 소비자는 이러한 표현을 사용하여 서버의 리소스 상태를 수정해야 합니다.
• Self-descriptive messages – 각 리소스 표현은 메시지 처리 방법을 설명하기에 충분한 정보를 전달해야 합니다. 또한 클라이언트가 리소스에 대해 수행할 수 있는 추가 작업에 대한 정보도 제공해야 합니다.
• Hypermedia as the engine of application state – 클라이언트에는 응용 프로그램의 초기 URI만 있어야 합니다. 클라이언트 응용 프로그램은 하이퍼링크를 사용하여 다른 모든 리소스와 상호 작용을 동적으로 구동해야 합니다.

1.2. Client-Server

클라이언트-서버 디자인 패턴은 클라이언트와 서버 구성 요소가 독립적으로 발전하는 데 도움이 되는 문제 분리를 적용합니다.

사용자 인터페이스 문제(클라이언트)와 데이터 스토리지 문제(서버)를 분리하여 여러 플랫폼에서 사용자 인터페이스의 이식성을 개선하고 서버 구성 요소를 단순화하여 확장성을 개선합니다.

클라이언트와 서버가 진화하는 동안 클라이언트와 서버 간의 인터페이스 / 계약이 깨지지 않도록해야합니다.

1.3. Stateless

상태 비저장은 클라이언트에서 서버로의 각 요청에 요청을 이해하고 완료하는 데 필요한 모든 정보를 포함해야 한다고 요구합니다.

서버는 이전에 서버에 저장된 컨텍스트 정보를 이용할 수 없습니다.

이러한 이유로 클라이언트 응용 프로그램은 세션 상태를 완전히 유지해야 합니다.

1.4. Cacheable

캐시 가능 제약 조건을 사용하려면 응답이 암시적 또는 명시적으로 자신을 캐시 가능 또는 캐시 불가능으로 레이블을 지정해야 합니다.

응답을 캐시할 수 있는 경우 클라이언트 응용 프로그램은 나중에 동등한 요청 및 지정된 기간에 대해 응답 데이터를 다시 사용할 수 있는 권한을 얻습니다.

1.5. Layered System

계층화된 시스템 스타일을 사용하면 구성 요소 동작을 제한하여 아키텍처를 계층적 계층으로 구성할 수 있습니다.

예를 들어, 계층화된 시스템에서 각 구성 요소는 상호 작용하는 바로 계층 너머를 볼 수 없습니다.

1.6. Code on Demand (Optional)

또한 REST를 사용하면 애플릿 또는 스크립트 형태로 코드를 다운로드하고 실행하여 클라이언트 기능을 확장할 수 있습니다.

다운로드한 코드는 사전 구현에 필요한 기능 수를 줄여 클라이언트를 단순화합니다. 서버는 코드 형태로 클라이언트에 전달되는 기능의 일부를 제공할 수 있으며 클라이언트는 코드를 실행하기만 하면 됩니다.

2. What is a Resource?

REST에서 정보의 주요 추상화는 리소스입니다. 우리가 이름을 지을 수있는 모든 정보는 자원이 될 수 있습니다. 예를 들어, REST 자원은 문서 또는 이미지, 임시 서비스, 다른 자원들의 콜렉션, 또는 비-가상 객체(예를 들어, 사람)일 수 있다.

특정 시간에 자원의 상태를 자원 표현이라고 합니다.

자원 표현은 다음으로 구성됩니다.

• the data
• the metadata describing the data
• and the hypermedia links that can help the clients in transition to the next desired state.

REST API는 상호 연결된 리소스의 어셈블리로 구성됩니다. 이 리소스 집합을 REST API의 리소스 모델이라고 합니다.

2.1. Resource Identifiers

REST는 자원 식별자를 사용하여 클라이언트와 서버 컴포넌트 간의 상호작용에 관련된 각 자원을 식별합니다.

2.2. Hypermedia

표현의 데이터 형식을 미디어 유형이라고 합니다. 매체 유형은 표현이 처리되는 방법을 정의하는 스펙을 식별합니다.

RESTful API는 하이퍼 텍스트처럼 보입니다. 정보의 모든 어드레스 가능 유닛은 명시적으로(예를 들어, 링크 및 id 속성들) 또는 암시적으로(예를 들어, 미디어 유형 정의 및 표현 구조로부터 파생된) 어드레스를 전달한다.

하이퍼 텍스트 (또는 하이퍼 미디어)는 정보가 사용자 (또는 오토 마톤)가 선택을 얻고 작업을 선택하는 어포던스가되도록 정보와 제어의 동시 표시를 의미합니다.

하이퍼텍스트는 브라우저에서 HTML(또는 XML 또는 JSON)일 필요는 없습니다. 기계는 데이터 형식과 관계 유형을 이해할 때 링크를 따라갈 수 있습니다.

— Roy Fielding

2.3. Self-Descriptive

또한, 자원 표현은 자기 설명적이어야 한다: 클라이언트는 자원이 직원인지 장치인지 알 필요가 없다. 리소스와 연결된 미디어 유형에 따라 작동해야 합니다.

따라서 실제로는 많은 사용자 지정 미디어 유형(일반적으로 하나의 리소스와 연결된 하나의 미디어 유형)을 만듭니다.

모든 미디어 유형은 기본 처리 모델을 정의합니다. 예를 들어 HTML은 하이퍼텍스트에 대한 렌더링 프로세스와 각 요소 주변의 브라우저 동작을 정의합니다.

미디어 유형은 리소스 메서드 GET / PUT / POST / DELETE / ... 일부 미디어 유형 요소는 "href 속성이있는 앵커 요소는 선택시 CDATA로 인코딩 된 href 속성에 해당하는 URI에서 검색 요청 (GET)을 호출하는 하이퍼 텍스트 링크를 만듭니다."

3. Resource Methods

REST와 관련된 또 다른 중요한 것은 리소스 메서드입니다. 이러한 자원 메소드는 자원의 두 상태 사이에서 원하는 전환을 수행하는 데 사용됩니다.

많은 사람들이 리소스 메서드를 HTTP 메서드 (예 : GET / PUT / POST / DELETE)와 잘못 연관시킵니다. Roy Fielding은 어떤 조건에서 어떤 방법을 사용해야하는지에 대한 권장 사항을 언급 한 적이 없습니다. 그가 강조하는 것은 균일 한 인터페이스 여야한다는 것입니다.

예를 들어, 대부분의 사람들이 HTTP PUT을 권장하는 대신 애플리케이션 API가 리소스를 업데이트하기 위해 HTTP POST를 사용하기로 결정하면 괜찮습니다. 그래도 응용 프로그램 인터페이스는 RESTful입니다.

이상적으로는 자원 상태를 전환하는 데 필요한 모든 것이 자원 표현의 일부가되어야합니다 - 지원되는 모든 방법과 표현을 떠날 형식을 포함합니다.

초기 URI (책갈피)와 의도 된 대상에 적합한 표준화 된 미디어 유형 집합 (즉, API를 사용할 수있는 모든 클라이언트가 이해할 것으로 예상)을 넘어서는 사전 지식이없는 REST API를 입력해야합니다.

이 시점부터 모든 응용 프로그램 상태 전환은 수신된 표현에 존재하는 서버 제공 선택사항의 클라이언트 선택에 의해 구동되거나 이러한 표현에 대한 사용자의 조작에 의해 암시되어야 합니다.

전이는 미디어 유형들 및 자원 통신 메커니즘들에 대한 클라이언트의 지식에 의해 결정(또는 제한)될 수 있으며, 이들 모두는 즉석에서 개선될 수 있다(예를 들어, 주문형 코드). [여기서 실패는 대역 외 정보가 하이퍼텍스트 대신 상호 작용을 유도한다는 것을 의미합니다.]

4. REST and HTTP are Not the Same

많은 사람들이 HTTP와 REST를 비교하는 것을 선호합니다. REST와 HTTP는 동일하지 않습니다.

REST != HTTP

REST는 또한 웹 (인터넷)을보다 능률적이고 표준으로 만들려고하지만 Roy Fielding은 REST 원칙을보다 엄격하게 사용하는 것을지지합니다. 그리고 사람들이 REST를 웹과 비교하기 시작하려고합니다.

Roy Fielding은 그의 논문에서 프로토콜 기본 설정이나 HTTP를 포함하여 구현 방향을 언급하지 않았습니다. 그때까지 우리는 REST의 6 가지 기본 원칙을 존중하고 있으며,이를 인터페이스 인 RESTful이라고 부를 수 있습니다.

5. Summary

간단히 말해서 REST 아키텍처 스타일에서 데이터와 기능은 리소스로 간주되며 URI(범용 리소스 식별자)를 사용하여 액세스됩니다.

리소스는 간단하고 잘 정의된 작업 집합을 사용하여 작동합니다. 또한 클라이언트가 HTML, XML, 일반 텍스트, PDF, JPEG, JSON 등과 같은 다양한 형식의 콘텐츠에 액세스할 수 있도록 리소스를 표현에서 분리해야 합니다.

클라이언트와 서버는 표준화된 인터페이스와 프로토콜을 사용하여 리소스의 표현을 교환합니다. 일반적으로 HTTP가 가장 많이 사용되는 프로토콜이지만 REST는이를 요구하지 않습니다.

자원에 대한 메타데이터가 사용 가능하며 캐싱을 제어하고, 전송 오류를 감지하고, 적절한 표현 형식을 협상하고, 인증 또는 액세스 제어를 수행하는 데 사용됩니다.

그리고 가장 중요한 것은 서버와의 모든 상호 작용이 상태 비저장이어야 한다는 것입니다.

이러한 모든 원칙은 RESTful 애플리케이션이 간단하고 가볍고 빠르도록 도와줍니다.

참조:

• REST APIs must be hypertext-driven
• REST Arch Style

Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST)