Younghoe.Info (final edition)

REST 학습을 위해 한국 IBM DeveloperWorks에서 REST로 검색하면 많은 결과나 나타난다. 처음 접하는 기사로는 REST, 웹 서비스, REST-ful 서비스 나 REST 서비스 작성하기 (한글) 가  좋다. REST, 웹 서비스, REST-ful 서비스는 REST의 HTTP 메소드 활용법에 대한 쉬운 설명으로 시작한다.


뒤이어 REST와 유사한 통신이 가능한 아키텍처를 제시하고, 예제 코드 위주로 설명한다. 저자가 제공하는 프레임워크 자체를 실전에 쓰일 용도보다는 내부 작동/구성 방식 이해에 도움을 준다. 실제로는 Spring 3.0의 MVC 모듈이나 기타 REST 지원 프레임워크를 쓰겠지만 어떻게 작동하고, 어떤 구성일 필요한지 이해하는 일은 유익하다.


그림에서 RESTful 도 아니고 REST-like라고 표기한 부분이 눈에 띈다. 명확한 이유를 제시하지는 않고 있다. 완전한 REST 아키텍처를 준수하지는 않는다는 의미로 이해할 수 있을 듯하다.  

REST, 웹 서비스, REST-ful 서비스가 빠르게 훑어 보려는 목적에 적합하다면, 흡사한 내용을 다루는 기사 REST 서비스 작성하기 (한글)는 설명이 상세하고 명확하다.

아쉬운 점은 스프링 사용자로서 가장 눈길을 끄는 기사가 영문 사이트에 있지만, 번역 기사가 없다는 점이다.

• Build RESTful web services using Spring 3
• Build RESTful web services with the Spring 3 MVC HttpMessageConverter feature
  

WS-* 를 통칭한 웹 서비스(Web Services)는 한물간(?) 듯 보인다. 사실 우리나라 SI 흐름을 보면 자체 개발한 원천 기술은 찾기 어렵고, 외부에서 도입하는 기반 기술은 짧은 주기로 떴다 가라앉곤 한다. Toby 형이 전해주는 해당 분야 전문가의 말에 따르면 RESTful은 간소하기에 처음에는 편리하지만, 개발을 진행할수록 어렵다고 한다. 사실 상식적인 일이다. 오랜 시간 존속한 산업 표준은 이윤을 추구하는 업체가 만든 자산이 있기 마련이다. 범용성을 추구하는 기술일수록 번거로운 일이 따르지만, 반대급부로 주어지는 혜택도 있기 마련이다.

요즘 모바일 붐에 편승해 RESTful 인기가 피부에 와 닿는다. 이런 상황에서 웹 서비스 개발을 새로 시작하는 프로젝트를 들었다. 어차피 알맹이가 중요하지만, 혹시 세상모르고 웹 서비스 추구하다가 비싼 WS-* 솔루션에 투자했다가 이내 RESTful로 다시 개발하지는 않기를 바란다.

일민 형이 Spring DM(OSGI) 이거 쓸만한겨? 링크를 소개하며 의견을 물었다. 체격(?)에 어울리는 글을 주로 쓰는 행각으로 미루어볼 때 자신이 하고 싶은 말이 많은데, 마치 사석에서 하는 가벼운 발언에 대해 기자회견을 하는 모양새가 두려웠던 것일까? 평소 가벼운 글쓰기를 즐기는 나를 부추긴다. 일과 중이었으니 그럴 시간 없다고 넘어갔는데, 귀가 후 발을 씻는데 갑자기 몇 자 적고 싶은 마음이 생겼다.

지난해 다른 사람에게 상처주는 글은 자제하겠다고 마음먹었기에 조금 망설여지긴 했다. 어제 미네르바를 처벌하려 한다는 소문에, 뚱딴지같이 친일파를 만난 듯한 꺼림칙한 기분을 느꼈다. 그래놓고선 이글에 대해 독선적으로 깎아내린다면 도둑놈 심보가 아닌가? 나 자신도 미숙하지만, 생각을 표현하는 행위를 반복하면서 발전했다고 믿기에 이 글을 쓰신 행동은 존중한다.

이제 진정 하고 싶은 말을 하겠다. 후유~ 성숙해지려는 노력은 참으로 어려운 일이다. :)

나는 이분의 주장을 반박할 생각은 없다. 단지 용어를 쓰는 데 있어서 일반적인 용법을 크게 벗어나 있음을 말하려 한다.


SOA는 구체적인 기술이 아니라 아키텍처에 대한 사고 체계이다. 위키피디아 SOA 페이지 어디에도 SOA를 어떤 기술을 써서 구현하라는 이야기는 나오지 않는다. SOA 구현을 위해 PHP 파일이나 MS-SQL을 쓸 수 있고 POJO 역시 쓸 수 있다. SOA는 사고 체계이기에 구현 과정에서 A4 지 100권을 쓸 수도 있고, 대화를 위해 휴대전화도 쓸 수 있다. :) 하지만, EJB나 POJO만으로 SOA를 구현하는 것은 불가능하다.


REST를 위키피디아^[각주:1]에서 찾아보면 아키텍처 스타일 가운데 하나임을 알 수 있다. POJO는 EJB가 아닌 일반 자바 객체를 말한다. 위 표현에 대입해보자. 


REST는 아키텍처 스타일이지 자바 객체 설계나 구현 스타일이 아니다. REST를 이루는 원칙을 준수해 구현한 경우 "RESTful" 이라 표현하는데, 이를 지원하는 프레임워크로 유명한 것이 Ruby on Rails, Restlet (for Java)와 Django (for Python) 등이다. REST는 자바로만 구현할 수 있지 않고, 더구나 POJO로만 구현하는 일은 현실적으로 불가능에 가깝다. 다만, Spring 프레임워크 3.0 버전은 최대한 POJO 중심으로 "RESTful" 웹 애플리케이션을 구현할 수 있도록 지원할 전망이므로 REST와 POJO과 전혀 무관하지는 않다.

학자나 교수가 아닌 이상 REST나 POJO에 대해 이야기하려고 명세서(Specification)까지 읽을 필요는 없겠지만, 모르는 단어를 쓸 때 사전을 찾듯 약간의 학습을 해야 다른 사람과 대화할만한 글을 쓸 수 있다.

* 토비형이 잘못 읽은 부분을 지적해서 해당 내용을 삭제합니다.

왜 REST(Representational State Transfer)인가 궁금했는데 Building Web Services the REST Way에 간결하고 명확한 설명이 있다.


위 내용을 기초로 개념 모델을 그려보면


모델을 한 눈에 와닿지 않는 것을 보면 아직 이해가 부족하다. 마소에서 읽은 창신님의 웹2.0 시대의 견인차 Open API에서 어떤 식으로 학습해야 할 지 배울 수 있다. Roy Fielding의 논문에서 다음 표를 보면 이해하는데 조금 도움이 된다.

REST Data Elements

Data Element	Modern Web Examples
resource	the intended conceptual target of a hypertext reference
resource identifier	URL, URN
representation	HTML document, JPEG image
representation metadata	media type, last-modified time

논문에는 REST가 등장하는 기술적 배경에 대해서 요약한 상태도(statechart)가 등장한다.

좀 더 잘 정리한 글을 보시려면: Open Resource. Open Web이 꾸는 Plaza의 꿈