REST의 정의

<br> REST(REpresentational State Transfer: 표현 상태 전송)는 웹 아키텍처 스타일이다.

HTTP 스펙 설계에 참여했던 로이필딩이라는 사람이 2000년대 발표한 네트워크(웹) 아키텍처 스타일이다. 여기서 네트워크 아키텍처 스타일이란 한가지의 웹 아키텍쳐 가 아니라 여러 가지 복수의 아키텍쳐의 공통된 성질, 양식 규정 혹은 독특항 방식의 집합을 네트워크 아키텍쳐 스타일이라고 한다. REST를 네트워크 아키텍쳐 스타일이라고 하지만, 사실 HTTP 기반위에 존재하는 아키텍쳐 스타일이므로 웹 아키텍처 스타일이라고 부르는 것도 틀린 표현은 아닌 것 같다.

RESTful은 어떤 대상이 REST 의 제약에 따르고 있고, 그래서 상당히 REST스럽다? REST답다 라는 형용사적 의미이다.

예를 들어 어떤 서버 A가 존재 한다고 하자. 이 A서버는 REST라는 아키텍츠 스타일의 제약을 충실히 따르고 있다면, 이 A 서버를 RESTful 한 서버라 부를 수 있다.

REST의 의미

REST는 수많은 아키텍처 스타일 중에서도, 특히 네트워크 시스템의 아키텍처 스타일 이다. 그리고 REST는 웹의 대표적인 아키택처 스타일인 클라이언트/서버를 기반으로 하는 복합 아키텍처 스타일이다. , 즉 로이필딩은 REST 기반으로 네트워크를 설계하면 효과적이라고 생각했다.

REST = 클라이언트/서버 + 스테이트리스 서버(Stateless Server) + 캐시(cache) + 유니폼 인터페이스(uniform Interface) + 계층화 시스템 + 코드 온 디맨

<br>

클라이언트/서버 말그대로 클라이언트 와 서버로 구성되어 있으며 클라이언트에서 request하면 서버에서 response한다.

스테이트리스 서버 클라이언트의 어플리케이션 상태를 서버에서 관리하지 않는다는 의미이다. 서버가 어플리케이션의 상태를 가지지 않게되면, 그만큼 서버 측의 구현이 갈결해지는 장점이 있다. 하지만 현실적으로 스테이트리스가 아닌 웹 서비스와 웹 API가 많이 사용된다. 특히 HTTP를 스테이트풀 하게 만드는 대표적인 것은 Cookie를 사용한 세션관리이다. REST의 관점에서 본다면, Cookie를 사용한 세션관리는 HTTP의 잘못된 확장이다. 다만 REST의 기준으로 잘못되었다고 해서, Cookie를 사용한 폼 인증을 그만둘 수 없는 것도 현실이다. Cookie는 스테이트리스 서버의 이점을 버린다는 것을 이해한 후 최소한으로 이용 해야 한다.

캐시 리소스의 신선도에 기초해, 한번 가져온 리소스를 클라이언트 쪽에서 돌려쓰는 방식.

유니폼 인터페이스 (리소스, http 메소드, 메세지) URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다. 예를 들어 HTTP1.1 에서 GET, POST등 8개의 메소드만 정의되어 있고, 보통은 이 이상 늘어나지 않는다. 어떻게 보면 확장성이 떨어진다고 보여지지만 이런 제약이 현재 웹의 통일된 인터페이스를 만들어 낸 것이다.

REST에서는 모든 것을 명사형 리소스로 표현하며, 의미가 명확한 한정된 HTTP 메소드를 사요하고, 메세지를 담아서 통신한다. 아래는 대표적으로 사용하는 메소드 4개이다.

<table> <tr><td>메소드명</td><td>기능</td></tr> <tr><td>get</td><td>search</td></tr> <tr><td>post</td><td>create</td></tr> <tr><td>put</td><td>update</td></tr> <tr><td>delete</td><td>delete</td></tr> </table>

<br> 아래는 실제 REST 메세지의 표현 형테이다. http://somthingweb/user/ 주소(리소스 url)에 POST(CREATE)해라 rocky라는 이름으 user를 이라는 의미를 갖는 메세지이다.

1
2
3
4
5
6
HTTP POST , http://somthingweb/user/
{
"user":{
"name":"rocky"
}
}

계층화 시스템

유니폼 인터페이스로 인해 발생되는 이점중 하나이다. 통일된 인터페이스로 인해 시스템 전체를 계층화 하기 쉽다. 프록시 서버, 로드벨런서 등등을 http 인터페이스로 통일하여 계층화 하여 사용 할수 있다.

코드 온 디맨드(code on demand)

프로그램 코드를 서버에서 다운 받아 클라이언트에서 실행하는 아키텍처 스타일이다. 처음에 이 개념은 서버에서 발생하는 부하를 클라이언트쪽으로 부담시켜 서버의 부하를 낮추것이 목적이었다.

예를 들어 javascript나 flash, java 애플릿 등이 여기에 해당한다. 반대로 jsp, asp 같이 백엔드에서 페이지를 렌더링해서 클라이언트에 보내는 경우, 수많은 화면 페이지들은 *.jsp 또는 *.asp 이런 확장자를 가지게 된다. 이는 화면단 소스가 백엔드 기술에 종속된다는 것을 의미한다. jsp, asp 이런 기술들은 백엔드에 프론트엔드가 기술적으로 종속된다는 단점이 있지만, 이런 단점을 무색하게 할 정도로 강력한 기능을 제공해 왔다.

하지만 근래 javascript의 눈부신 발달, jquery, ajax 기타 수많은 블라블라.js 등으로 인해 이런 백엔드 서버페이지 기술, jsp, asp이런 것들이 제공하는 기술들을 대체하는 시대가 되었다. 본래의 서버의 부하를 낮추는 기능 뿐만 아니라 프론트 엔드가 서버에 독립적으로 동작할수 있는 특성이 생겨버렸다.

요즘의 REST, RESTful 하다라는 말이 유행하게 된 가장 큰 이유는 발전된 javascript, jquery, ajax를 통해 백엔드에 독립적인 프론트엔드 개발이 가능한 환경 즉 코드 온 디멘드가 가능한 환경이 되었기 때문이라고 생각된다. 특히 ajax통신은 http + xml or json 형태의 통신형태로 인해 REST가 지향하는 유니폼 인터페이스를 구현하는 기반이 되었다고 생각된다.

jquery, ajax를 이용하여 프론트엔드는 백엔드에 종속되지 않고 백엔드 시스템과 통신할수 있다. 이런 시점에서 적절한 웹 아키텍처가 필요했고 로이필딩이 2000년대 논문을 통해 발표한 REST라는 웹 아키텍처 스타일이 트랜드상 선호되는것 같다.