REST에 대한 이해

REST 아키텍쳐

REST는 웹의 창시자(HTTP) 중의 한 사람인 Roy Fielding의 2000년 논문에 의해서 소개되었다. 현재의 아키텍쳐가 웹의 본래 설계의 우수성을 많이 사용하지 못하고 있다고 판단했기 때문에, 웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍쳐를 소개했는데 그것이 바로 Representational safe transfer (REST)이다. 

Basic of REST 

한마디로 REST를 정리하면 HTTP URI + HTTP Method 이다. URI로 대상 자원을 명시하고 Method로 해당 자원에 대한 행위를 정의한다. 

Resource

REST의 가장 큰 특징중의 하나가 모든 자원을 Resource 즉 자원으로 표현한다는 것이다. 이 Resource는 HTTP URL에 의해서 표현된다. 예를 들어 javastudy 사이트의 bcho 라는 사용자를 표현하면  http://www.javastudy.co.kr/users/bcho 로 표현이 가능하고, 서울 강남구 사무실의 9층의 HP프린터를 표현할때는 http://printers/localtion/seoul/kangnamgu/9f/hp 식으로 표현을 한다. 이로써 HTTP URI를 통해서 모든 Resource를 표현이 가능하다. 

Action

그렇다면 해당 자원에 대한 행동은 어떻게 표현할것인가? 이는 HTTP Method를 사용한다.

l       자바스터디 사이트의 bcho에 대한 회원 정보를 가지고 오고 싶을때는
URI : http://www.javastudy.co.kr/users/bcho
Method : GET  

l       또는 해당 회원을 생성하고 싶을 때
URI : http://www.javastudy.co.kr/users/bcho
Method : POST
PayLoad
 <payload>
  <name>조대협</name>
     :
 </payload>

l       해당 회원을 삭제하고 싶을 때
URI : http://www.javastudy.co.kr/users/bcho
Method : DELETE

l       해당 회원에 대한 정보를 변경하고 싶을 때
URI : http://www.javastudy.co.kr/users/bcho
Method : PUT
PayLoad
 <payload>
  <name>조대협</name>
    :
 </payload>

즉 HTTP 프로토콜에 정의된 4개의 메서드들이 자원(Resource)에 대한 CRUD를 정의한다.

HTTP Method	의미
POST	Create
GET	Select
PUT	Create or Update
DELETE	Delete

REST의 문제점

그런데 문제가 있다. 우리가 사용할 수 있는 메서드가 4가지 밖에 없다는 것이다. 예를 들어 send email이라던가, Log write와 같은 메서드들은 HTTP Method로 표현하기가 모호해진다.

기존의 프로그래밍 스타일이 Function이나 Method를 중심으로 한 행위 중심적인 접근이었기 때문에, REST가 지향하고 있는 자원 기반의 접근에 맞지 않는 것이다. 오히려 DBMS와 같이 CRUD를 가지고 있는 자원에 대해서는 적절하게 적용된다. 이런 이유가 REST를 단순하게 프로토콜이라고 부르지 않고 아키텍쳐라고 정의한 이유이다. 

그렇다면 이 문제를 어떻게 해결해야 할 것인가?

사실 CRUD만으로 모든 행위를 표현할 수 는 없다. Control성이나 함수성의 의미를 갖는 것들을 표현해야 하는데, 이런 경우는 HTTP/PUT이나 POST 메서드를 사용하거나 또는 함수에 대한 의미를 재해석하는 접근이 필요한데. Send Mail을 예를 들어보면 “메일을 보낸다” 라는 행위를 “누구한테 보내는 메일을 생성한다” 라는 의미로 바꾸면 다음과 같은 표현이 가능하다.  HTTP/POST http://www.xxx./sendmail/to/{emailaddress}

 그래도 문맥상으로 의미 변환이 불가능한 경우가 생긴다.

이런 경우는 HTTP/PUT과 URI를 사용하여 control의 의미를 부여한다. 사용자 ID bcho에 대한 등급 변경을 하는 경우는 다음과 같이 표현할 수 있다.

예를 들어 http://www.xxx/users/bcho/upgrade 

사실상 REST 기반의 아키텍쳐를 설계하려면 가장 어려운 것이 이 URI를 어떻게 정의하는 것이다. REST의 장점중 하나는 이 URI와 HTTP Method만으로도 쉽게 의미를 파악할 수 있다는 것이기 때문에, URI 정의에 많은 노력을 기울이는 것이 좋다 

장단점 

REST의 장점

기존의 웹 인프라를 그대로 이용할 수 있다.

가장 큰 장점중의 하나일거다. 기존 HTTP를 그대로 사용하기 때문에, Remote Call을 할때도 방화벽을 새로 뚫어야 하느니등의 요건이 없고, L4등의 로드 밸런서 장비들도 그대로 사용이 가능하다.

무.엇.보.다. 웹캐쉬 서버를 그대로 사용할 수 있다. 모든 Resource가 URI로 Unique하게 표현되기 때문에, 웹 캐쉬상에 보관될 수 있고, 특히나 SELECT성의 Operation은 이 캐쉬에 의해서 실제 Biz Transaction을 타지 않고 바로 리턴될 수 있기 때문에, 성능과 리소스 활용 측면에서 어마어마한 장점을 가지고 있다. 

쉽다.

웹서비스와 비교해보면 웹서비스는 스펙이 정말 많다. WS*-I, WS Reliable Messaging, WS Transaction 등등등 스펙 덩어리다. 그러나 REST는 별도의 SPEC이 없다. 보통 Defactor 표준이라고 하는데, HTTP URI와 Method만 잘 지켜서 사용하면 그게 REST다. 

REST의 문제점

표준이 없다. 즉 관리가 어렵다.

REST가 요즘 들어 부각되는 이유 자체가 WebService의 복잡성과 그 표준의 난이도 때문에 Non Enterprise 진영 (Google,Yahoo,Amazone) 을 중심으로 집중적으로 소개되었다. 데이터에 대한 의미 자체가 어떤 비즈니스 요건 처럼 Mission Critical 한 요건이 아니었기 때문에 서로 데이터를 전송할 수 있는 정도의 상호 이해 수준의 표준만이 필요했지 Enterprise 수준의 표준도 필요하지 않았고, 벤더들 처럼 이를 주도하는 회사도 없었다.

 단순히 많이 사용하고 암묵적으로 암암리에 생겨난 표준 비스무리 한 것이 있을 뿐이다. (이런 것을 Defactor 표준이라고 부른다.) 

그런데 문제는 정확한 표준이 없다보니, 개발에 있어서 이를 관리하기가 어려워진다는 것이다. 표준을 따르면 몇가지 스펙에 맞춰서 개발 프로세스나 패턴을 만들 수 가 있는데, 이는 표준이 없으니, REST 기반으로 시스템을 설계하자면 사용할 REST에 대한 자체 표준을 정해야 하고, 어떤 경우에는 REST에 대한 잘못된 이해로 인하여 잘못된 REST 아키텍쳐에 이건 REST다 라는 딱지를 붙이는 경우가 많다. 실제로 WEB 2.0의 대표 주자격인 Flickr.com 도 REST의 특성을 살리지 못하면서 RPC 스타일로 디자인한 API를 HTTP + XML을 사용했다는 이유로 Hybrid REST라는 이름을 붙여서 REST 아키텍쳐에 대한 혼란을 초래했다. 

주. Flickr의 Hybrid Rest는 어떤 Operation을 처리할 때,  http://URL/operation?name=operationname 과 같은 형태로 메서드를 Query String으로 넘기는 형태를 사용했다. 언뜻 봐서는 RESTful한 디자인 같지만, 모든 Resource의 URI는 같고 operation을 Query String으로 나눈것에 불과 하기 때문에, 모든 Resource에 Unique 한 URI를 부여하는 REST의 원래 설계 원칙과 벗어난다.  그런데, 국내에는 이런 형태의 디자인을 REST로 이해하고 있는 사람들이 많은 것 같아서 걱정이고 몇몇 포탈에서도 이런 형태의 서비스를 제공하는 것으로 알고 있다.

 

REST적인 접근과 설계가 필요하다.

위에서도 잠깐 설명했지만,  REST는 WebService와 같은 프로토콜이 아니다. REST는 아키텍쳐이다 Resource를 기반으로 하는 아키텍쳐이기 때문에 시스템 설계도 Rest 에 맞는 설계가 필요하다. 

Alternative Key의 사용

예를 들어 Resource를 표현할 때,  이러한 Resource는 DB의 하나의 Row가 되는 경우가 많은데, DB의 경우는 Primary Key가 복합 Key 형태로 존재하는 경우가 많다. (여러 개의 컬럼이 묶여서 하나의 PK가 되는 경우) DB에서는 유효한 설계일지 몰라도, HTTP URI는 / 에 따라서 계층 구조를 가지기 때문에, 이에 대한 표현이 매우 부자연 스러워진다.

예를 들어 DB의 PK가 “세대주의 주민번호”+”사는 지역”+”본인 이름일 때” DB에서는 이렇게 표현하는 것이 하나 이상할 것이 없으나, REST에서 이를 userinfo/{세대주 주민번호}/{사는 지역}/{본인 이름} 식으로 표현하게 되면 다소 이상한 의미가 부여될 수 있다.

이외에도 resource에 대한 Unique한 Key를 부여하는 것에 여러가지 애로점이 있는데, 이를 해결하는 대안으로는 Alternative Key (AK)를 사용하는 방법이 있다. 의미를 가지지 않은 Unique Value를 Key로 잡아서 DB Table에 AK라는 필드로 잡아서 사용 하는 방법인데. 이미 Google 의 REST도 이러한 AK를 사용하는 아키텍쳐를 채택하고 있다.

그러나 DB에 AK 필드를 추가하는 것은 전체적인 DB설계에 대한 변경을 의미하고 이는 즉 REST를 위해서 전체 시스템의 아키텍쳐에 변화를 준다는 점에서 REST 사용시 아키텍쳐적인 접근의 필요성을 의미한다. 

사실 그외에도 REST적인 설계를 하기 위해서는 Resource간의 관계를 href로 (링크)로 표현하는 기법,Versioning 방법,Naming Rule, ESB를 이용한 Cross cutting concern의 처리와 Routing 등 여러가지 고려 사항이 있으나, 아키텍쳐 설계 방법과 고급 REST에 대해서는 다음 기고 (고도화된 REST 아키텍쳐)에 대해서 논의 하기로 하겠다. 

REST에 대한 잘못된 인식

REST = HTTP + XML 프로토콜?

프로젝트 성격상 고도화된 REST 시스템에 대한 설계가 필요했기 때문에 필자가 작년 중반즘에 국내의 한 커뮤니티 사이트에 REST에 대한 토론을 제안한적이 있었는데. 대부분의 사람들의 REST에 대한 이해는 REST는 HTTP를 써서 XML을 보내면 REST라고 생각하고 있었다.

절대 아니다.

REST는 웹의 특성을 잘 활용하여 자원을 리소스로 표현하는 아키텍쳐이다.(프로토콜이 아니다) 물론 HTTP는 사용해야 한다. 그러나 XML은 필수가 아니다. JSON이나 YAML과 같은 다른 표현 언어를 사용해도 무방하다. 리소스에 대한 표현과 웹의 특성을 얼마나 잘 활용했는가가 REST 아키텍쳐를 제대로 이해하는가에 대한 판단 기준이 될것이다. 

이번 글을 쓰는 이유중의 하나도 국내에 제대로된 REST에 대한 기고나 원칙을 설명한 문서가 없는 것 같아서 다소 부족한 글이지만 정리한다. 

REST는 WebService보다 쉽다.?

사실 그렇지도 않다. 맨 바닥에서 개발한다면야 REST가 더 쉽다. 자체 표준을 만들어서 Simple XML로 메시지를 정의해서 단순히 HTTP로만 보내면 되니까.. 그런데 이건 서비스 제공자 입장이다. 서비스를 사용하는 입장에서는 HTTP Client로 요청을 보내서 리턴받은 XML이나 JSON 데이터를 일일이 파싱해서 처리해야 한다.

 그러나 WebService는? 이미 잘 짜여진 표준 때문에, POJO나 JAX-WS등으로 코딩만 하면 자동으로 웹서비스가 생성된다. 무엇보다 WSDL에 의해서 정해진 서비스 Contract에 의해서 Client Stub을 자동으로 생성할 수 있기 때문에, 프로토콜 Spec을 전혀 모르더라도 마치 Java Library를 호출해서 사용하는 것처럼 쉽게 사용할 수 있다. 

본인의 경우에는 REST보다 WebService개발이 더 쉬워 보인다. 가장 쓰기 좋은 것은 복잡도가 낮고 잘 정리된 WS-I 기반의 WebService를 사용하는 것이 가장 간단하고 생산성면에서도 좋다. 

REST의 전망

국내에서는 아직 REST에 대한 수요가 그다지 많지는 않다. 복잡도가 높은 시스템 설계를 기피하는 현상때문인지.. 아니면 아직 개방형 시스템에 대한 수요가 많지 않아서인지…

그러나 이미 해외의 유수 사이트들은 REST 기반의 아키텍쳐를 통해서 서비스 하고 있으며 대표적인 Open API 업체중의 하나인 Amazon역시 기존에 WebService로 개발되어 있었던 Open API들을 REST 기반으로 Migration할 계획이다. REST가 Defactor표준이기는 하지만 웹세상에서는 이미 무시하기 어려운 표준으로 자리잡아 가고 있다. 

또한 이렇게 오픈 진영에서 탄생한 REST가 J2EE Spec중의 하나인 JAX-RS로 (JSR311)로 추가되어 다음 JEE6 버전에 포함될 예정이다. (오픈 소스로는 Sun의 Jersey 라는 프레임웍과 Apache CXF에 포함도어 있다. 그리고 Spec화 된다해도 어디까지나 구현 방법에 대한 Spec이지 REST가 가지고 있는 그 자유도는 매우 높다. ) REST에 대한 표준화의 일환으로 WebService의 WSDL과 유사한 WADL이라는 Spec이 나오기는 했지만 REST 서비스의 URI정도를 표현하는 뿐이지, 실제 Operation안에 들어가는 Message의 Scheme등을 표현하고 있지 않고 있기 때문에 여전히 REST에 대한 Service Contract 표준은 없다고 보는 것이 맞을 것이고 이것이 앞으로 장점이 될지 단점이 될지는 판단하기 어렵다. 

출처 : http://bcho.tistory.com/321