Rest architecture

From 탱이의 잡동사니
Revision as of 14:35, 21 February 2018 by Pchero (talk | contribs) (→‎REST 아키텍쳐에 대한 기본)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Overview

Rest 아키텍쳐에 대한 소개. 원문은 이곳<ref>http://bcho.tistory.com/category/%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90%20/WEB%202.0</ref><ref>http://blog.naver.com/PostView.nhn?blogId=complusblog&logNo=220986337770</ref>에서 확인할 수 있다.

REST 아키텍쳐에 대한 기본

REST 아키텍쳐

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

Basic of REST

한마디로 REST를 정리하면 HTTP URI + HTTP Method 이다. URI로 대상 자원을 명시하고 Method로 해당 자원에 대한 행위를 정의한다. '무엇(HTTP URI로 정의된 리소스)을 어떻게(HTTP Method + Payload)'로 잘 정의된 API를 REST API 라고 할 수 있다.

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를 사용한다.

  • 자바스터디 사이트의 bcho에 대한 회원 정보를 가지고 오고 싶을때는
URI : http://www.javastudy.co.kr/users/bcho
Method : GET
  • 또는 해당 회원을 생성하고 싶을 때
URI : http://www.javastudy.co.kr/users/bcho
Method : POST
PayLoad
 <payload>
  <name>조대협</name>
     :
 </payload>
  • 해당 회원을 삭제하고 싶을 때
URI : http://www.javastudy.co.kr/users/bcho
Method : DELETE
  • 해당 회원에 대한 정보를 변경하고 싶을 때
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 표준은 없다고 보는 것이 맞을 것이고 이것이 앞으로 장점이 될지 단점이 될지는 판단하기 어렵다.

Advanced REST

REST 는 HTTP의 장점을 이용하여 좀더 발전된 형태의 구현이 가능하다.

하나의 예로 이 글은 http://www.infoq.com/articles/subbu-allamaraju-rest 를 이용하여 편역하여 설명한다. 예를 들기위해서 은행의 계좌이체를 하는 시나리오를 가정해서 생각해보자.

인터넷 뱅킹 계좌 이체 시나리오의 구현

STEP 1. 인터넷 뱅킹 시스템에 로그인을 한다.

STEP 2. 사용자 ID로, 해당 사용자가 가지고 있는 계좌 목록을 조회한다.

http://bank.org/accounts?findby=7t676323a 

200 OK

Content-Type: application/xml;charset=UTF-8

 <accounts xmlns="urn:org:bank:accounts">
    <account>
        <id>AZA12093</id>
        <customer-id>7t676323a</customer-id>
        <balance currency="USD">993.95</balance>
    </account>
    <account>
        <id>ADK31242</id>
        <customer-id>7t676323a</customer-id>
        <balance currency="USD">534.62</balance>
    </account>
</accounts>

사용자 ID 7t76323a에 대해서 두개의 계좌 AZA12093과 ADK31242 가 리턴되고 각 계좌의 잔액이 함께 리턴된다. 각 계좌 번호를 조회했기 때문에 각 계좌의 상세 정보는

http://bank.org/account/AZA12093 http://bank.org/account/ADK31242

STEP 3. 계좌 이체를 하는 시나리오를 보면 

POST /transfers
Host: bank.org
Content-Type: application/xml;charset=UTF-8

<transfer xmlns="urn:org:bank:accounts">
    <from>account:AZA12093</from>
    <to>account:ADK31242</to>
    <amount currency="USD">100</amount>
    <note>RESTing</note>
</transfer>

AZA12093에서 ADK31242로 100 USD를 이체하는 것을 HTTP POST를 통해서 보낸다.계좌 이체가 성공하면 다음과 같은 결과값이 리턴된다. 

201 Created
Content-Type: application/xml;charset=UTF-8
<transfer xmlns="urn:org:bank:accounts">
    <from>account:AZA12093</from>
    <to>account:ADK31242</to>
    <id>transfer:XTA8763</id>
    <amount currency="USD">100</amount>
    <note>RESTing</note>
</transfer>

이때 주의해서 볼 것은 리턴값이 HTTP 200이 아니라 HTTP 201이다. 이 시스템의 경우 계좌이체가 바로 발생하는 것이 아니라 비동기적으로 나중에 발생하는 형태로 가정하기 때문에, 계좌 이체 요청이 접수되었다라는 의미로 HTTP 201 Created를 리턴하고 이체 신청 번호 XTA8763을 리턴한다.

STEP 4. 하루가 지난후에, 계좌 이체가 된 내용을 다시 확인해보면

http://bank.org/check/XTA8763 

GET /check/XTA8763
Host: bank.org 

200 OK

Content-Type: application/xml;charset=UTF-8
<status xmlns="urn:org:bank:accounts">
    <code>01</code>
    <message xml:lang="en">Pending</message>
</status>

해당 계좌 이체 요청이 Pending이 되어 있는 것으로 나타난다.

진보된 형태의 REST를 이용한 인터넷 뱅킹 계좌이체 시나리오의 구현

언뜻 보면 상당히 잘 구현된 형태의 REST처럼 보이지만, 이는 실제 REST의 장점을 제대로 살린 아키텍쳐라고 볼 수 없다.

REST는 첫번째로 URI를 이용한 자원의 식별이 가능해야 하고,

두번째로 HTTP 프로토콜의 여러 기능들 특히 HTTP Header들을 이용해서 리소스에 대한 다양한 접근 방법을 표현할 수 있어야 한다. 예를 들어서 Sync/Async 식의 Message Exchange Pattern, Correlation ID 등을 이용한 CALL BACK, 웹캐쉬를 이용하기 위한 Last Update Time등의 메타 정보를 HTTP HEADER에 정의해야 하며 Contents Type등을 통한 Input과 Output Data Format에 대한 정의가 가능할 수 있다.

세번째로는 링크를 이용한 리소스간의 관계나 현재 리소스에 대한 상태 정보를 표현할 수 있어야 한다.

그러면 이 특징을 기반으로 해서 앞에서 작성했던 계좌 이체 시나리오를 재 구현해보자

STEP 1. 인터넷 뱅킹 시스템에 로그인을 한다.

STEP 2. 사용자 ID로, 해당 사용자가 가지고 있는 계좌 목록을 조회한다. 

200 OK
Content-Type: application/vnd.bank.org.account+xml;charset=UTF-8

<accounts xmlns="urn:org:bank:accounts">
    <account>
        <id>AZA12093</id>
        <link href="http://bank.org/account/AZA12093" rel="self"/>
        <link rel="http://bank.org/rel/transfer edit"
              type="application/vnd.bank.org.transfer+xml"
              href="http://bank.org/transfers"/>

        <link rel="http://bank.org/rel/customer"
              type="application/vnd.bank.org.customer+xml"
              href="http://bank.org/customer/7t676323a"/>
        <balance currency="USD">993.95</balance>
    </account>

    <account>
        <id>ADK31242</id>
        <link href="http://bank.org/account/ADK31242" rel="self"/>
        <link rel="http://bank.org/rel/transfer"
              type="application/vnd.bank.org.transfer+xml"
              href="http://bank.org/transfers"/>
        <link rel="http://bank.org/rel/customer"
              type="application/vnd.bank.org.customer+xml"
              href="http://bank.org/customer/7t676323a"/>
        <balance currency="USD">534.62</balance>
    </account>

</accounts>

앞서 설명한것과 다소 다른 형태의 리턴값이 오게되는데, 먼저 살펴볼 부분은 Content-Type이다. : application/vnd.bank.org.account+xml; 리턴 형태의 Content-Type이 리턴된다. 먼저 +xml은 이 문서의 포맷이 xml임을 의미하며 vnd.bank.org.account는 리턴 데이터의 구조를 정의한다. (마치 XML 스키마와 같이, 실제로 UNIQUE한 이름으로 INPUT또는 OUTPUT으로 사용되는 XML 스키마의 이름에 ID를 부여해서 사용하면, REST의 약점중의 하나인 데이터 형의 미정의에 대한 약점을 보완할 수 있다. )

또다른 변화점은 LINK부분이 추가되었다는 것이다. 이 LINK는 현재 자원의 상태가 어떤 상태로 변화될 수 있으며, 상태를 변화시키기 위해서는 어떤 URI를 이용하면 된다는 것을 설명한다. 또는 이 자원과 관련성이 있는 다른 자원에 대한 연관 관계를 표현하며 호출시에 리턴되는 데이터 형태에 대해서 Content-Type으로 정의할 수 있다. 이렇게 RETURN되는 메시지 자체에 다른 자원으로의 연결 상태와 데이터 형태등이 정의되면 서비스에 대한 별도의 정의가 없이도, 자원에 대한 사용 방법과 관계를 알 수 있기 때문에 이러한 특성을 REST에서는 self-descriptive message라고 한다.

<account> 

        <id>ADK31242</id>

        <link href="http://bank.org/account/ADK31242" rel="self" type=”application/vnd.bank.org.account+xml”/>

        <link rel="http://bank.org/rel/transfer"
              type="application/vnd.bank.org.transfer+xml"
              href="http://bank.org/transfers"/>

        <link rel="http://bank.org/rel/customer"
              type="application/vnd.bank.org.customer+xml"
              href="http://bank.org/customer/7t676323a"/>

        <balance currency="USD">534.62</balance>

이 부분을 살펴보면 세가지 변화 상태를 볼 수 있다. Self와 http://bank.org/rel/transfer 그리고 http://bank.org/rel/customer 이다.

첫번째로 http://bank.org/rel/transfer 로 이 계좌에 대해서 “계좌 이체”를 할 수 있는 관계(또는 기능)을 정의하며, 계좌 이체를 하기 위해서는 http://bank.org/transfers URL에 보내면 되고 리턴값은 application/vnd.bank.org.transfer+xml 형태가 된다.

두번째 self는 이 Account 자체에 대한 좀더 제사한 정보를 나타내며 http://bank.org/account/ADK31242 를 통해서 조회할 수 있으며 리턴 되는 데이터 형태는 application/vnd.bank.org.account+xml 로 리턴 됨을 정의한다.

세번째 http://bank.org/rel/customer 는 고객 정보를 나타내며 http://bank.org/customer/7t676323a 를 통해서 조회가 가능하고 리턴되는 데이터 형태는 application/vnd.bank.org.customer+xml 이 된다.

STEP 3. 실제로 계좌 이체를 수행한다.

STEP 2에서 리턴 받은 transfer 관계의 URL로 아래와 같은 데이터를 전송한다. 

POST /transfers
Host: bank.org
Content-Type: application/vnd.bank.org.transfer+xml;charset=UTF-8

<transfer xmlns="urn:org:bank:accounts">
    <from>account:AZA12093</from>
    <to>account:ADK31242</to>
    <amount currency="USD">100</amount>
    <note>RESTing</note>
</transfer>

리턴값은 아래와 같다. 

201 Created
Content-Type: application/vnd.bank.org.transfer+xml;charset=UTF-8 

<transfer xmlns="urn:org:bank:accounts">
    <link rel="self"
          href="http://bank.org/transfer/XTA8763"/>
    <link rel="http://bank.org/rel/transfer/from"
          type="application/vnd.bank.org.account+xml"
          href="http://bank.org/account/AZA12093"/>

    <link rel="http://bank.org/rel/transfer/to"
          type="application/vnd.bank.org.account+xml"
          href="http://bank.org/account/ADK31242"/>

    <link rel="http://bank.org/rel/transfer/status"
          type="application/vnd.bank.org.status+xml"
          href="http://bank.org/check/XTA8763"/>

    <id>transfer:XTA8763</id>
    <amount currency="USD">100</amount>
    <note>RESTing</note>

</transfer>

STEP 4. 계좌 이체 진행 상태를 확인한다. 계좌 이체 진행 상태를 확인하기 위해서는 STEP 3에서 리턴된 http://bank.org/check/XTA8763 을 이용하여 확인할 수 있다.

결론

사실 여기서 언급하고자 한 부분은 HTTP의 Content-Type을 이용한 데이터 타입의 정의와 Link를 이용한 리소스간의 관계 정의 방법이다. 많은 REST 관련글을 보면 비슷한 사상들을 가지고는 있지만 아직 “이거다” 하는 식의 표준 디자인 방법은 존재하지 않는다.

위의 예제에서도 Content-Type을 통해서 In/out data format을 정의할 수 는 있지만 고민해보면 Link에 정의된 type만으로는 out(return) data format을 정의할 수 있을지 몰라도 input에 대한 정의는 빠져 있다. 또한 다른 디자인에서는 XML의 namespace의 URI에 실제 XML Scheme의 URI를 정의해서 데이터 타입을 정의하는 방법론도 있다.

또한 Link를 사용하는 방법은 프로토콜 차원에서는 리소스간의 관계를 정의를 하는것이라서 언뜻 보면 좋아보일 지는 모르지만 실제 구현시에는 여러가지 제약사항을 만들어 낼 수 있다.

이 글은 HTTP의 좀더 활용을 통해서 좀더 발전된 형태의 REST 디자인 방법의 하나의 예시를 설명한 것 뿐이고, 좀더 실용적인 REST 디자인은 더 많은 고려가 필요하리라 생각된다.

References

<references />

Retrieved from "http://wiki.pchero21.com/index.php?title=Rest_architecture&oldid=2901"