[REST-Delphi #1] 델파이 DataSnap을 이용한 REST 프로그래밍 요약

REST Servers in Delphi XE Using DataSnap

[REST-Delphi #1] 델파이 DataSnap을 이용한 REST 프로그래밍 요약        

본 연재는 Marco Cantu, http://blog.marcocantu.com 블로그를 참고하여 나름 쉽게 델파이에서 REST 프로그래밍 하는 기법에 대해 설명한다.

 

REST(Representational State Transfer)는 IT정보 산업에 중요한 임펙트를 줄 수 있는 웹서비스(Web Service)를 위한 새로운 아키텍처로, 이미 대부분의 메이저 회사(구글, 야후, 아마존, 마이크로소프트)가 다양한 소스로 부터 데이터를 머지하고 공유하기 위한 기술로 도입하고 활용하고 있다.

 

REST는 HTTP와 XML고 같은 간단한 기술적인 배경만을 가지고도 쉽게 구현이 가능한 아키텍처로 델파이에서는 이미 2010 버전 부터 DATASNAP 인프라를 통해 REST를 지원하기 시작 했고 XE 버전 부터 웹브로커(WebBroker)와 통합되었고, 웹에 의해 노출되는 Method를 위한 자바스크립트 프록시(Proxy)를 통해 보다 향상된 모델을 제공한다.

먼저 REST에 대한 기본적인 아키텍처에 대해서 알아 보자.

1. REST(REpresentational State Transfer) 아키텍처?

  Roy Fielding(웹[HTTP]의 창시자중 1인)이 현재 아키텍처가 웹의 본래 설계의 우수성을 많이 사용하지 못하고 있다는 가정하에 웹의 장점을 최대한 활용할 수 있는 아키텍처를 소개 함

 

2. REST의 특징

 

  ○ REST = HTTP URI + HTTP Method로 URI로 대상 자원을 명시하고 Method 및 Parameter로  행위를 정의

 

  ○ Resource

     - 가장 큰 특징으로 모든 자원을 Resource, 자원으로 표현 

     - Resource는 HTTP URI로 표현

     - 표현 예)

        . 목적 : 바보(babo) 라는 사용자를 표현

          http://www.rest.com/users/babo

        . 목적 : 서울시청

          http://www.rest.com/korea/seoul/cityhole

 

   

  ○ Action

     - Action에 대한 정의 (CRUD)

HTTP Method	설명	비고
POST	개체생성(CREATE)
GET	SELECT
PUT	CREATE OR UPDATE
DELETE	DELETE

 

 

     - 자원을 핸들링하기 위한 액션(행동)은 HTTP Method로 표현

     - 바보에 대한 회원정보를 얻기 위한 예)

       URL : http://www.rest.com/users/babo

       Method : GET

     - 바보(babo) 회원을 생성하고 싶을 경우

       URL : http://www.rest.com/users/babo

       Method : POST

          Users

         <userdata>

             <name>babo</name>

             ....

          </userdata>

- 해당회원을 삭제하고 싶을 경우

  URL : http://www.rest.com/users/babo

  Method : DELETE

- 해당회원(babo) 정보를 변경하고 싶을 경우

  URL : http://www.rest.com/users/babo

  Method : PUT

  Users

  <userdata>

    <name>babo</name>

    <age>45</age>

    ...

  </userdata>

 

 

3. REST의 장단점

 

  ○ 장점

- 기존의 웹 인프라를 그대로 이용

대부분의 WEB서비스를 이용하는 클라이언트는 80포트로 대변되는 웹HTTP 포트가 방화벽에 열려 있다. 따라서 기존 HTTP를 이용한 호출이 가능하고 기존 서비스 인프라를 그대로 활용 가능하다는 장점이 있다. 그렇기 때문에 기존 웹시스템이 이용하는 웹캐시 서버등도 그대로 이용 가능하다.

- 웹서비스(SOAP)처럼 별도의 스펙이 정의되어 있지 않다. 따라서 호출 HTTP URI와 Method만 잘 지켜서 사용하면 그 자체가 REST가 된다.

 

  ○ 단점

- 표준이 없다(장점이자 단점)

- 상호간에 자체 REST표준을 정의하고 공유 되어야 함을 의미 함

- REST는 프로토콜 표준이 아닌 아키텍쳐이다 따라서 REST적인 접근과 설계가 필요함

- DB 표현시 다중 키를 표현하기 어색하므로 Alternative KEY(대체키)를 사용하는 식의 REST적 접근

 ○ 설계시 고려할 점

- Resource간의 관계를 href(링크)로 표현하는 기법

- Versioning 방법

- 네이밍(Naming) 방법

- 설계방법에 대한 추가 고민

 

4. REST에 대한 오해

 

○ REST = HTTP + XML 프로토콜 : HTTP를 이용하여 XML 데이터를 전달하는 프로토콜(X)

- REST는 웹의 특성을 잘 활용하여 자원을 리소스로 표현하는 아키텍처(프로토콜 X)

- XML은 필수가 아니고 JSON, YAML등과 같은 다른 표현이 가능하다.

 

○ REST는 SOAP보다 쉽다? (△)

- 구현의 입장에서는 SOAP보다 REST가 더 쉬워 보인다(표준이 없기 때문)

- SOAP은 잘 정의된 프로토콜을 사용하기 때문에 디코딩이 가능하며 예측 가능하다.

- REST는 전달받은 XML 또는 JSON 데이터를 일일이 파싱해서 사용해야 한다.

 

5. 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 표준은 없다고 보는 것이 맞을 것이고 이것이 앞으로 장점이 될지 단점이 될지는 판단하기 어렵다. 

가장 큰 장점은 단순성과 자유도에 있으니 독자는 각자 가치 판단 필요하다.