REST - What is REST (1)

REST 2016. 8. 22. 16:56

REST

What is REST? — (1)



Introduction

REpresentional State Tranfter의 약자로 2000년도 웹(HTTP)의 공동 창시자인 Roy Fielding의 박사 논문에 소개되었다. REST는 기존의 Web-Service들이 HTTP를 적극적으로 활용하지 못하는 문제를 해결하기 위해서 제안되었다. 얼핏보면 HTTP를 대체하는 Protocol처럼 인식되나, REST는 결코 Protocol이 아니다. HTTP를 보다 HTTP답게 만들기 위한 방법론 즉, Network based Software Architecture를 위한 Architectural Style & Design 이다. 많은 사람들이 REST를 마치 SOAP(Simple Obeject Acess Protocol)과 같이 WEB Application의 Protocol로 착각하는 경우가 많은데, REST는 WEB Application의 동작 원리와 그 동작의 효율을 설명하는 Design Paradigm 이다.

REST는 철저히 Resource 중심적 설계를 중시하고, Create / Read / Update / Delete (CURD)에 해당하는 HTTP의 4 가지 Method POST / GET / PUT / DELECT 를 그 용도에 맞게 정확하게 사용함으로써, 기존의 Service 중심의 Web Application(SOA - Service, Verbs 중심)을 Resource 중심의 Web Application(ROA - Resource, Nouns)으로의 변화를 일으켰다.

REST는 Protocol이 아닌 설계론이라는 것을 이해하자. 이러한 REST Architecture에 맞게 설계된 Design을 “RESTful”이라 표현하기도 한다.

REST는 오늘날 Google, Amazon, Flicker, Tweeter와 같은 Open Service 업체들의 주도 하에 적극 적용되어, 표준 아닌 표준 Defecto Standard로 자리를 잡아가고 있다.


REST 6 Constraints

Web이나 Application이 다음의 6가지 조건을 만족하게 설계되었다면 “REST(ful)하게 설계했다”라고 말할 수 있다.

  • Client-Server
  • Stateless
  • Cacheable
  • Layered System
  • Code on demand (optional)
  • Uniform Interface

REST를 특징짓을 수 있는 6 가지 조건에 대해 간략하게 알아 보자.

Client-Server

Client를 Server로부터 분리하는 것이다.
예로, Client로 하여금 Server가 관리하고 저장하는 Data들에 무관심하게 만들어서, 서버 의존적인 Client code를 좀 더 자유롭게하여 이동성(Portability)를 향상시킨다. 즉 Server와 Client 간의 역할 분담을 명확히 하고 서로 분리하여 Server와 Client의 자율도를 높힌다.

REST Server는 그러한 Resouece를 관리하는 API를 제공하며, Client는 사용자 인증이나 Context(Session, Login 정보)등을 직접 관리하고 책임진다. Server는 Client의 User Interface나 User State에 상관없이 Server 기능에 집중할 수 있어, 보다 간단하게(Simplicity), 보다 쉽게(Scalable) 확장될 수 있다.





Stateless

REST의 가장 대표적인 특징이라 하겠다. 이전과 이후에 대한 직접적인 정보가 필요없이 직관적으로 REST Server가 제공하는 API를 통해 Resource에 접근한다. 즉 세션정보와 같은 Context를 저장할 필요가 없기 때문에, 서비스의 자유도 또한 높아지고 로드밸런싱이라든지 기타 유연한 아키텍처의 적용이 가능하다.

단, Client는 자신을 구분하기 위해 정보를 서버에게 충분히 전달해야 한다.(API Key or Token)





Cacheable

REST는 HTTP 기반의 Web protocol을 그대로 활용하기 때문에 기존 Web이 가지는 특징들을 그대로 가질 수 있다.
HTTP 프로토콜 기반의 Load balance나 SSL, HTTP가 가진 가장 강력한 특징중의 하나인 Caching 기능을 적용할 수 있다. Web Service에서 60% ~ 80% 가량의 Transcation이 조회(GET) Transaction인 것을 생각한다면, Stateless Server의 무수한 Resource들을 Web-Chache server, Proxy server 나, Client 등에 직접 Caching 하는 것은 많은 장점이 있다는 것을 쉽게 알 수 있다.
구현은 HTTP 프로토콜 표준에서 사용하는 “Last-Modified” 태그나 E-Tag를 이용하면 Cache를 구현할 수 있다.





Client-Cache-Sateless-Server

REST의 3가지 특징 Client-Server, Stateless, Cache를 아래 그림으로 잘 표현되어 있다.





Layered System

Layered System 역시 Cacheable 특징처럼 HTTP의 특징을 그대로 활용할 수 있다.
System Scaling을 위해 Gateway, Proxy server, Firewall 과 같은 또 다른 Layer들을 수용할 수 있다.





Code on Demand (Optional)

Server는 실행가능한 코드 (Executable Code)를 Client에게 전송해줌으로써, Client의 기능들을 일시적으로 확장하거나 커스터마이징 할 수 있다. Java Applet이나 JavaScript 등이 대표적인 예라 하겠다.
Server는 Client의 Resource Request에 대하여 Resource와 함께 JavaScript와 같은 code를 함께 Return 하여 Client의 기능 확장과 설정을 할 수 있어, 사용자 인식에 대한 성능 및 효과를 높힐 수 있다.





NEXT> 

블로그 이미지

MidnightCow

위즈네트 칩(W5300, W5200, W7100, W7500) 개발자

,