REST, RESTful API

REST(Representational State Transfer : 자원의 전달 상태) - 네트워크 아키텍쳐

REST는 2000년에 Roy Fielding에 의해 사용된 단어이다. HTTP를 느슨한 커플링 어플리케이션으로 개발하기 위한 아키텍쳐 스타일이다. 종종 웹 서비스 개발에 사용된다. REST는 저수준에서 어떻게 구현되어야하는지 어떠한 규칙도 강제하지 않으며, 고수준의 디자인 가이드를 제시하고 구현은 각 당사자들에게 맡긴다.

 

(참로 Roy Fielding은 1996년부터 1999년까지 HTTP 1.0의 기존 디자인에 기반을 둔 HTTP 1.1와 병행하여 REST 구조의 스타일을 개발하였다.)

 

* REST의 원칙 가이드

1. Client, Server

- 클라이언트와 서버가 서로 독립적으로 분리되어있어야 한다.

- 서버와 클라이언트 역할이 분리된다. 인터페이스가 변경되지 않는 한 독립적으로 교체 및 개발 될 수 있다.

- 인터페이스와 데이터 처리 영역이 분리될 수 있어 프런트는 다양한 플랫폼의 가용성이, 백엔드는 확장성이 증가된다.

2. Stateless

- 요청에 대해서 클라이언트의 상태를 서버에 저장하지 않는다.

- 클라이언트에서 서버로의 각 요청에는 그 요청을 이해하는 데 필요한 모든 정보가 포함되어야 한다.

3. Cacheable

- 캐쉬 제약사항은 요청에 응답하는 데이터가 캐쉬 가능한지, 아닌지 암묵적으로든 명시적으로 표시되도록 요청한다.

(요청에 대한 응답 내의 데이터에 해당 요청은 캐시가 가능한지 불가능 한지 명시해야 한다.)

- 응답이 캐시가 가능하다면, 클라이언트 캐시는 같은 요청이 왔을 때, 같은 응답 데이터를 재사용 할 권리가 주어진다.

4. 계층화(Layered System)

서버와 클라이언트 사이에, 방화벽, 게이트웨이, proxy등 다양한 계층 형태로 구성이 가능하고 확장할 수 있다.

계층화된 시스템 아키텍처는 상호작용하는 계층 너머를 "볼" 수 없도록 구성 요소 동작을 제한하도록 층을 나눈다.

5. 인터페이스 일관성

-인터페이스의 일관성을 지키고, 아키텍처를 단순화시켜 작은 단위로 분리하며, 클라이언트, 서버가 독립적으로 개선될 수 있어야 한다.

 

(전체적인 시스템 아키텍처를 간단하고 잘 파악할 수 있도록 하기 위한 약속된 Interface는 아래에 4가지를 따로 소개한다.)

6. Code on Demand

- 자바 애플릿, 자바스크립트, 플래시 등 특정한 기능을 서버로부터 클라이언트가 전달받아서 실행하도록 한다.

- 클라이언트가 사전에 미리 구현하도록 요구받는 기능의 수를 줄여준다.

 

자원

 REST 에서 가장 핵심은 자원(resrouce)이다. 이름이 붙여질 수 있는 어떠한 정보라도 자원이 될 수 있다: 문서, 이미지, 일시적 서비스, 다른 자원의 모음, 현실의 객체(사람). 등등. REST는 컴포넌트끼리 상호작용에 포함된 특별한 자원을 식별하기위해 자원 식별자(resrouce identifier)를 사용한다.

 

 특별한 타임스탬프에서 자원의 상태는 자원의 표현(resource representation)이다. 자원의 표현은 데이터, 데이터를  설명하는 메타 데이터 그리고 클라이언트가 다음 필요한 상태로 이동하도록 돕는 하이퍼미디어링크로 구성되어있다.

 

 표현의 데이터 형식은 미디어타입(media type)이다. 미디어타입은 표현이 어떻게 진행되는지 정의하는 특별명세서를 식별한다. 진정한 RESTful API 하이퍼텍스트의 모양을 가진다. 모든 주소지정 가능한 정보의 유닛들은 명시적으로(링크, id 속성) 혹은 암시적으로(미디어타입 정의와 표현 구조로부터 파생된) 주소를 전달한다.

 

하이퍼텍스트(하이퍼미디어)는 정보와 통제의 동시 표현을 의미한다. 그러한 정보는 사용자가 선택을 얻고 실행을 하도록 행동 유도를 한다. 하이퍼텍스트는 브라우저에서 HTML(XML 혹은 JSON)일 필요가 없다는 사실을 기억하라. 기계들이 데이터 형식과 관계 타입을 이해했을 때 기계들은 링크를 따라서 작동한다. (by Roy Fielding)

 

 게다가, 자원의 표현은 자기 서술적(self-descriptive) 이 가능하다: 클라이언트는 자원이 고용자인지 장치인지 알 필요가 없다. 자원과 결합하여 미디어-타입의 기초에서 작동해야만 한다. 따라서, 많은 커스텀 미디어 타입 생성을 끝낼 수 있다. - 1개의 미디어타입과 1개 자원의 결합

 

모든 미디어 타입은 일반적인 프로세스 모델을 정의한다. 예를 들어, HTML은 하이퍼텍스트의 렌더링 과정과 브라우저 행동을 정의한다. HTML은 GET/PUT/POST/DELETE와 연관이 없다. 오히려 몇몇의 미디어타입 요소들은 프로세스 모델을 정의할 것이다. 프로세스 모델이란, "href특성을 가진 a 요소는 하이퍼텍스트 링크를 만드는데, 선택되었을 때, CDATA-인코딩 href 특성에 따라서 URI의 GET을 유도한다" 와 같다.

 

자원 메서드

REST와 관련된 또다른 중요한 것은 원하는 이동을 수행하기 위한 자원 메서드(resource method)이다. 많은 사람들은 자원 메서드를 HTTP GET/PUT/POST/DELETE 메서드와 연관짓는 실수를 저지른다

 

Roy Fielding은 메서드가 사용되어야 하는 조건에 대해 어떠한 권고사항을 언급한 적이 없다. 그가 강조한 것은 일관적인 인터페이스여야 한다는 것이다.(uniform interface) 만약에 사용자가 HTTP POST로 자원을 업데이트 하기로 결정했다면, (대부분의 사람들은 HTTP PUT을 추천하겠지만) - 옳은 선택이고 어플리케이션 인터페이스는 RESTful하다.

 

이상적으로, 자원의 상태를 변화시키는 것이 필요한 모든 것이 그 자원의 응답 API의 일부분이 되어야 하며, 여기에 메서드와 표현을 떠날 상태가 포함된다. 

 

REST API는 초기 URI 및 의도된 청중(API를 사용할 수 있는 모든 클라이언트가 이해할 것으로 예상되는)에 적합한 표준화된 미디어 유형 집합을 넘어서지 않는 선에서 입력해야 한다. 그 시점부터, 모든 애플리케이션 상태 변경은 수신된 표현에 존재하거나, 해당 표현들의 사용자 조작에 의해 내포된 서버에서 제공된 선택들 중에 클라이언트의 결정에 의해서 수행되어야 한다. 변경은 클라이언트의 미디어타입에 대한 지식과 자원 커뮤니테이션 메커니즘에 의해 제한 될 수 있다. 둘다 즉석에서 개선될 수 있다.(code-on-demand)

 

RESTful API를 설계하는 또다른 방법은 쿼리 기반 API 결과들이 요약된 정보와 함께 링크의 목록들이 표현되는 것이다. 기존의 자원 표현의 배열의 형태가 아니다. 왜냐하면 쿼리는 자원들의 확인에 적합하지 않기 때문이다.

 

1. 자원의 식별(identification of resources)

웹 기반의 REST에서는 리소스 접근을 할 때 URI를 사용한다

https: // foo.co.kr/user/100

Reseource : user

식별자 100

 

2. 메세지를 통한 리소스 조작(manipulation of resources through representations)

HTML, XML, JSON, TEXT등으로 web은 다양한 방식으로 데이터를 전달한다.

 

그중에 어떤 타입의 데이터인지 알려주기 위해 HTTP Header 부분에 contet-type을 통해서 데이터 타입을 지정해 줄 수 있다.

또한 리소스 조작을 위해서 데이터 전체를 전달하지 않고, 메시지로 전달한다.

 

3. 자기서술적 메세지(self-descriptive messages)

요청하는 데이터가 어떻게 처리되어져야 하는지 충분한 데이터를 포함할 수 있어야 한다

Http Method와 Header 정보, 그리고 URI의 포함되는 정보로 표현

GET : https://foo.co.kr/user/100

POST : https://foo.co.kr/user

PUT : https://foo.co.kr/user/100

DELTE : https://foo.co.kr/user/100 

 

그 외에 담지 못한 정보들은 URI의 메세지를 통하여 표현한다.

 

4. Application 상태에 대한 엔진으로써 하이퍼미디어(hypermedia as the engine of application state)

REST API를 개발할 때 단순히 Client요청에 대한 데이터 응답이 아니라 

관련된 리소스에 대한 Link 정보까지 포함되어져야 한다.

 

이러한 조건들을 잘 갖춘 경우 RESTFul하다고 표현하고, REST API라고 부른다.

 

REST와 HTTP는 다르다!

많은 사람들이 HTTP를 REST와 비교하기를 선호한다. 하지만 REST와 HTTP는 다르다

 

REST != HTTP

비록, REST은 웹(인터넷)을 보다 간소화하고 표준으로 만들기 위해 REST 원칙을 더 엄격하게 사용하기를 권장한다. 그래서 사람들은 REST와 웹(HTTP)를 비교하려고 시도했다. Roy fileding은 그의 연설에서 구현지침에 대해 이야기 한 적이 없다. - 어떠한 프로토콜 선호나 HTTP라도. REST의 6가지 가이드 원리를 따르고 있다면, 당신의 인터페이스가 RESTful하다고 말할 수 있다.

 

간단히 말해서, REST 아키텍쳐 스타일에서 데이터와 기능은 자원으로 고려되며 URIs를 통해 접근된다. 자원들은 단순하고 잘 정의된 일련의 작업을 사용하여 작동된다. 대게, 클라이언트와 서버는 표준화된 인터페이스와 프로토콜을 사용하여 자원의 표현을 교환한다. - 대게 HTTP를 이용한다.

 

자원들은 자원들의 표현에서 분리(디커플링)된다. 그래서, HTML, XML, 일반 text, PDF, JPEG, JSON, 등과 같은 다양한 형식으로 콘텐츠에 접근할 수 있다. 예를 들어, 자원에 대한 메타데이터는 사용가능하고, 캐싱을 통제하고, 전송 에러를 감지하고, 적절한 표현 포멧을 협상하고 접근 통제나 인증을 수행하기 위해서 사용된다. 그리고 대게 가장 중요한 것은, 자원의 모든 상호작용은 stateless이다.

 

 

 

 

출처

https://restfulapi.net/