REpresentational State Transfer(REST)

REpresentational State Transfer(REST)

• World Wide Web(WWW, W3)과 같은 분산 하이퍼미디어 시스템을 위한 Software Architecture의 한 형식이다.

RESTful

• RESTful은 일반적으로 REST라는 Architecture를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.

구조

Resource, 자원

• Uniform Resource Identifier(URI)를 뜻한다.
• 모든 자원에 Server에 고유한 ID로 존재한다.
• 각 자원은 ‘/cs/{subject}’ 형식으로 구성된다.

Verb, 행위

• Client는 URI를 이용해 Resource를 제공하기 위해 HTTP Method를 사용한다.

Representation of Resource, 표현

• Request에 대한 모든 Response에 해당한다.
• Request에 대한 Response 주체의 상태를 HTTP Status로 제공한다.
• HTML, XML, JSON 등 Format의 Payload로 Request에 대한 응답을 Response Body를 제공한다.
• Response에 대한 상세 정보를 Response Header에 담아 제공한다. (Ex. API Key, …)

규칙

• Uniform Resource Identifier(URI)는 정보(Information)의 자원(Resource)을 표현(Representation of Resource)해야 한다.
• 자원(Resource)에 대한 행위(Verb)는 HTTP Method으로 표현해야 한다.

특징

Uniform Interface, 일관된 인터페이스

Resource identification in requests, 요청에 대한 리소스 식별

• 개별 Resource는 Request에서 식별된다.
• 예를 들어 RESTful 웹 서비스에서 URI를 사용한다.

Resource manipulation through representations, 표현을 통한 리소스 식별

• Client는 연결된 메타데이터를 포함하여 자원의 표현(Representation of Resource)을 보유하면 Resource 상태를 수정하거나 삭제할 수 있는 충분한 정보를 보유한다.

Self-descriptive messages, 자기 설명 메시지

• 각 메시지에는 메시지 처리 방법을 설명하는 데 필요한 충분한 정보가 포함되어 있다.
• 예를 들어 미디어 유형에 따라 호출할 파서를 지정할 수 있다

Hypermedia as the engine of application state[HATEOAS], 애플리케이션 상태의 엔진으로서의 하이퍼미디어

• REST Application의 초기 URI에 액세스한 REST Client는 Server에서 제공하는 링크를 동적으로 사용하여 필요한 모든 Resource를 검색할 수 있어야한다.
• 액세스가 진행되면 Server는 현재 사용 가능한 다른 Resource에 대한 하이퍼링크가 포함된 텍스트로 응답한다.

Stateless, 무상태성

• 각 Request에 대한 상태 정보를 Server에 저장하지 않는다.

Cacheable, 캐시 가능

• World Wide Web에서와 같이 Client는 Response를 캐싱할 수 있어야 한다.
• 잘 관리되는 캐싱은 Client-Server의 상호작용을 부분적으로 또는 완전하게 제거하여 Scalability와 성능을 향상시킨다.

Layered System, 계층형 구조

• Client는 Server에 직접적으로 연결되었는지, Intermediary Servers를 이용하여 간접적으로 연결되었는지 확인이 불가능하다.
• Intermediary Servers의 경우, Load Balancing과 Schared Chaches 기능을 제공함으로써 시스템 규모 확장성을 향상시키는데 유용하다.

Client-Server

• Architecture를 단순화, 분리함으로써 Client-Server의 의존성이 줄어든다.
• User Interface와 Data Storage 문제를 분리하면 여러 플랫폼에서 User Interface의 이식성이 향상된다.

Code on demand(Optional)

• Server에서 코드 전송으로 Client에서 실행 가능해야한다.(EX. Java applet, Js, …)

장점

• HTTP Protocol의 인프라를 그대로 사용하므로 REST API사용을 위한 별도의 인프라를 구축할 필요가 없다.
• HTTP Standard Protocol에 따르는 모든 Platform에서 사용이 가능하다.
• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
• Server와 Client의 역할을 명확하게 분리한다.

단점

• REST API의 표준이 존재하지 않는다.
• HTTP Method가 제한적이다.

Reference

Wiki-REST