블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

Jersey로 구현하는 자바 REST 서비스


 

이번 회에서는 REST의 개념을 바탕으로 JAVA 언어로 REST를 구축하는 방법에 대해서 알아보도록 한다.

JAVA 기반의 REST구현 방법에는 여러 가지가 있으나 근래에 웹서비스처럼 REST도 구현을 쉽게 도와줄 수 있는 프레임웍을 제공한다. 웹서비스의 구현 개발 표준이 JAX-WS였다면 REST에 대한 구현 표준은 JAX-RS이며 그 레퍼런스 구현으로는 Apache CXF Sun(지금은 오라클) Jersey가 있다. 본 문서는 Sun Jersey를 기준으로 작성되었다.

기본 REST 서비스 구현

먼저 이클립스를 인스톨하고 New > Project > Dynamic Web Project로 새로운 프로젝트를 생성한다.



프로젝트가 생성되었으면 Jersey를 사용하기 위해서 라이브러리의 설정등을 해야한다.



REST를 실행하는 서블릿 컨테이너를 서블릿으로 등록하고, 이 웹애플리케이션의 모든 URL REST 컨테이너내에서 실행되도록 <servlet-mapping> 부분에 url-pattern으로 정의한다. (특정 URL 패턴만 REST로 실행하도록 하고 싶으면 이 url-pattern 부분만 조정하면 된다.)

이제 앞의 연재에서 .NET WCF로 진행한 것과 같은 예제를 JAVA Jersey로 구현해보자



먼저 ValueObject를 위와 같이 구현한다. ValueObject REST 구현체상에서 JAVA XML을 상호 변환하여 맵핑 시켜주는 역할을 하며 이는 Java XmlBinding 프레임웍인 JAXB를 사용한다. Serialize되기 때문에 클래스 선언시에는 반드시 Serializable 인터페이스를 implements 하도록 한다.

반드시 클래스 앞에 @XmlRootElement Annotation을 이용해서 본 클래스가 JAXB를 이용해서 XML 변환을 사용할것이라는 것을 지정한다. 이때 name을 지정해서 XmlElement의 이름을 명시적으로 지정한다. (본 예제에서는 클래스명이 ContactVo이기 때문에 명시적으로 이름을 정해주지 않으면 Xml 로 변환시 클래스 이름을 따라서 <contactVo>로 변환된다.)

위의 ValueObject Xml로 변환되면 다음과 같은 모양이 된다.

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

- <Contact>

  <email>111</email>

  <name>22</name>

  <phone>123123</phone>

  </Contact>

다음으로는 이 ValueObject들을 저장할 Dao를 작성한다. 나중에 DB에 연동하고 싶으면 이 Dao 부분을 DB 연동 부분으로 바꾸면 되지만, 본 예제는 REST 자체의 구현에 집중하기 때문에, 간단하게 HashTable ContactVo email Key 값으로 저장한다



다음으로는 실제 CREATE,READ,UPDATE,DELETE를 지원하는 REST 서비스를 작성한다.



클래스에 @Path 어노테이션을 이용하여 REST 리소스의 URI 경로를 정의한다. URI FULL 경로는 http://웹서버/{WebApplication(WAR) URI}/{@Path 어노테이션으로 정의한 경로}이다.
REST 애플리케이션은 FirstREST라는 경로에 배포되는 것으로 설정하였기 때문에 이 리소스의 경로는 http://localhost/FirstREST/Contact이 된다.

각각의 HTTP Method Java 메서드를 맵핑 시키기 위해서는 각각 @PUT,@GET,@POST,@DELETE  Annotation을 사용한다. 여기서 주목해야 하는 부분은 URI를 통해서 인자를 넘겨 받는 부분인데, @Path Annotation을 사용하여 URI상에 인자가 있을 경우 정의하고, 인자를 @PathParam을 통해서 실제 Java 변수와 맵핑 시켜줘야 한다. 예를 들어 ../Contact/{email} URI에서 {email}을 인자로 사용하고 싶으면 위의 Delete 메서드와 같이 @Path(“{email}”)로 정의하고, URI @PathParam(“email”)String email 로 맵핑 시켜줘야, Java 변수 email로 값이 맵핑 된다.

여기까지 했으면 기본적인 REST가 컴포넌트가 완성되었다. 이제 컴파일을 하고 Eclipse에서 Project > Export 메뉴를 이용하여 WAR Export하여 Tomcat이나 JBoss등의 Web Application 서버에 배포하고 테스트를 진행하면 된다.

REST 구현에 있어서 자주 사용되는 Annotation들은 다음과 같다.

@QueryParam

URI QueryString 을 사용하여 method parameter를 전달한다. Parameter의 값은 자동으로 decoding 되며 자동 deocoding을 사용하지 않을때에는 @Encoded 를 사용한다.

@PathParam

URI path String 을 사용하여 method parameter를 전달 한다. Parameter의 값은 자동으로 decoding 되며 자동 deocoding을 사용하지 않을때에는 @Encoded 를 사용한다.

@Context

annotation 을 사용하여 UriInfo , Request, HttpHeader 같은 값들을 class field , method parameter로 전달한다.

@CookieParam

HTTP Cookie 의 값을 method parameter로 전달한다.

@HeaderParam

HTTP header 의 값을 method parameter  전달한다.

REST 컴포넌트 테스트 (SOAP UI)

불행히도 Sun Jersey Implementation .NET WCF와는 달리 별도의 REST 테스트 기능을 지원하지 않는다. 그래서 별도로 테스트 환경을 설정해야 한다. 가장 널리 사용되는 REST 테스트 도구로는 soapUI라는 도구가 있다. http://www.soapui.org 에서 다운받을 수 있다. 다운을 받아서 설치를 한 후 실행을 한다.

File > New SoapUIProject를 선택하여 새로운 테스트 프로젝트를 생성한다. 생성된 프로젝트에서 New REST Service를 선택하면 새로운 서비스 EndPoint를 넣게 되는데, 서비스명은 테스트할 서비스 이름 (아무거나)을 넣고, EndPoint에는 웹서버의 URL(IP,PORT)를 넣는다.



다음으로 Resource를 정의해야 하는데, Create,Delete,Put ./Contact/{email} 형태의 리소스이고, Post ./Contact 형태의 리소스이기 때문에, 먼저 ./Contact 리소스를 만들고 ./Contact/{email}리소스를 그 차일드 리소스로 만든다. 위에서 만든 서비스에서 New Resource를 선택하고 리소스명은 “Contacts” EndPoint /FirstREST/Contact (FirstREST는 이 REST 서비스가 배포되는 URI) 을 입력한다.



다음으로 해당 리소스에 New REST Method를 이용하여 새로운 메서드를 추가하는데, POST에 대한 메서드를 추가한다.



POST REST Request가 만들어 졌다. 이제 해당 Request를 선택하여 테스트창을 열어보자



테스트 창에서 아래 부분에 POST로 보낼 HTTP BODY XML 데이터를 입력하고 실행 버튼을 누르면 POST 요청을 보낸 것이다좌측의 Raw 탭을 이용하면 실제로 전송되는 HTTP Request를 볼 수 있다.



이제 HTTP GET을 이용해서 Resource가 제대로 생성되었는지 확인을 하자.

앞에서 생성한 Contacts 리소스에서 오른쪽 버튼을 클릭하여 New Child Resource 메뉴를 선택한다. Resource 이름을 Contact으로 정의하고, end Point“/{email}”을 추가하고, Extract Param 버튼을 클릭하면 이 {email}을 변수로 취급해준다. 이때 중요한 것이 Style인데, Template으로 선택되어야 한다. Style에 따라서 변수를 HTTP URI에 실어서 보낼지, HTTP Header에 넣을지, Query String등에 넣을지를 선택할 수 있다.



마찬가지로 New Method 메뉴가 나오는데, HTTP GET 메서드로 선택하고 getMethod라는 이름으로 새로운 메서드를 정의한다.



새로 생성한 메서드를 테스트 해보자, 위의 그림처럼 좌측 부분에 앞에서 정의한 email 변수에 값을 지정할 수 있다. 앞의 POST 메서드에서 “carry” 라는 이름으로 리소스를 만들었으니 emailcarry를 지정하고 실행 버튼을 누르면 위의 좌측 메뉴 처럼 XML로 리턴값을 보여준다.

같은 방법으로 PUT,DELETE에 대한 테스트 케이스를 만들 수 있다

본 예제에서는 가장 기본적인 부분만 설정하였는데, SoapUI의 경우 부하테스트를 통한 성능 측정까지 가능하기 때문에 Micro benchmark등에 활용이 가능하니 참고하기 바란다.

List 형 데이터 처리

자아 지금까지 단순한 REST 구현에 대해서 알아보았다. 이번에는 List 타입을 어떻게 핸들링하는지 알아본다. List 타입을 리턴하기 위해서는 ContactService.java에 다음 메서드를 추가한다.

이때 반드시 리턴 데이터 타입에 <ContactVo> List 개별 항목이 어떤 데이터 타입을 가지고 있는지를 정의해줘야 자바 객체를 JAXB XML 변환할 있다.

//ContactService.java 추가

@GET

    @Produces("text/xml")

    public List<ContactVo> GetList()

    {

        return dao.getList();      

    }

 

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

- <contactVoes>

- <Contact>

  <email>bycho</email>

  <name>Byungwook.Cho</name>

  <phone>123123</phone>

  </Contact>

- <Contact>

  <email>carry</email>

  <name>Carry.Cho</name>

  <phone>123123</phone>

  </Contact>

</contactVoes>

에러처리

에러 처리역시 매우 단순하다.

WebApplicationException을 사용하되, HTTP Error코드를 인자로 넘겨주면 된다.

Throw new WebApplicationException (400)                             

@Consumes @Produce

JAX-RS에서는 @Consume @Produce라는 Annotation을 지원하는데, @Consume HTTP Request를 받을 때 어떤 형태로 받을 것인 가이다. 현재는 디폴트로 xml request로 받게 되어 있지만, json이나 mime 타입 같은 확장 타입도 지원한다반대로 @Produce는 생성해내는 결과값의 형태에 대해서 정의하는데, @Produce에서 단순하게 타입을 json으로만 정해주면 결과값이 XML이 아닌 json 형태로 리턴된다..

 

3회에 걸쳐서 REST에 대한 개념, .NET JAVA를 이용한 실제 코드 구현에 대해서 살펴보았다. 다음회에서는 마지막으로 엔터프라이즈 시스템에 REST를 적용할 때 필요한 아키텍쳐 적인 면에 대해서 살펴보도록 하겠다.

REST 연재-1회 REST 아키텍쳐의 기본

아키텍쳐 /WEB 2.0 | 2009.05.27 23:20 | Posted by 조대협

1회 – REST 아키텍쳐에 대한 기본(DRAFT)

자바스터디 조대협
http://bcho.tistory.com

 

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

결론

REST는 그 단순성과 웹의 특성을 최대한 활용한다는 장점 때문에 해외에서는 이미 급격하게 전파되고 있으며 오픈 진영에서 개발된 기술로는 드물게 표준기술(JSR-311)로 채택되는 사례까지 만들었다. 

그러나 그 높은 자유도 때문에 통제나 관리가 어려워서 아직까지는 Enterprise System에서는 널리 사용되고 있지 않고 서비스 시스템 위주로 사용되고 있으며, 국내에서는 잘못된 REST에 대한 이해 부제와 OPEN API의 미활성화로 아직까지는 잘 사용되고 있지 않다. 

 해외의 여러 유수 서비스 업체들이 이미 REST 기반의 서비스를 주류로 하는 만큼 국내 개발자들도 REST에 대해서 준비를 할 때가 되지 않았나 싶다. 

다음 기고에서는 좀더 자세하게 고도화된 REST 아키텍쳐에 대해서 살펴보도록 하겠다.

'아키텍쳐  > WEB 2.0' 카테고리의 다른 글

REST 관련 강좌  (0) 2009.06.03
REST 아키텍쳐에 대한 연재를 시작합니다.  (2) 2009.05.27
REST 연재-1회 REST 아키텍쳐의 기본  (15) 2009.05.27
AJAX Overview  (1) 2009.04.09
REST의 반격?  (0) 2008.12.08
오픈 환경과 우물안의 개구리....  (0) 2008.09.16