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
  

REST에 대해 문외한일 때 글 하나 쓰면서 그린 그림

• Representational State Transfer (REST)
• a simpler alternative to SOAP- and Web Services Description Language (WSDL)-based Web services ... 하지만, 일민형이 만난 웹서비스 전문가에 따르면 REST가 시작은 쉽지만 갈수록 첩첩산중이라 WS-*가 깊이 들어가면 도리어 쉽다고 하는데...
• REST defines a set of architectural principles by which you can design Web services that focus on a system's resources, including how resource states are addressed and transferred over HTTP by a wide range of clients written in different languages. 출처: http://www.ibm.com/developerworks/webservices/library/ws-restful/
• 정작 처음 등장한 논문 Roy Fielding's dissertation, "Architectural Styles and the Design of Network-based Software Architectures." 을 통해서는 반향이 적었다.
• a concrete implementation of a REST Web service follows four basic design principles:
• Use HTTP methods explicitly. (고전인 RFC 2616 다시 보기)
• To create a resource on the server, use POST.
• To retrieve a resource, use GET.
• Web caching tools (crawlers) and search engines에 의해 의도치 않는 상태 변환을 막으려면 파라미터 대신 POSTㄴ

• POST /users HTTP/1.1
  
  Host: myserver
  
  Content-Type: application/xml
  
  <?xml version="1.0"?>
  
  <user>
  
    <name>Robert</name>
  
  </user>
  
          

• To change the state of a resource or to update it, use PUT.

• PUT /users/Robert HTTP/1.1
  
  Host: myserver
  
  Content-Type: application/xml
  
  <?xml version="1.0"?>
  
  <user>
  
    <name>Bob</name>
  
  </user>
  
  

• To remove or delete a resource, use DELETE.
• Be stateless.
• REST Web services need to scale to meet increasingly high performance demands.
• Stateful 모형
• Stateless 모형
• A stateless service not only performs better, it shifts most of the responsibility of maintaining state to the client application. ... the server is responsible for generating responses and for providing an interface that enables the client to maintain application state on its own
• This aspect of RESTful Web service design can be broken down into two sets of responsibilities as a high-level separation
• Server: 상태가 없으니 캐시 하기 좋고, 상태 대신 네비게이션 위한 링크를 포함
  
• Client application: Cache-Control response header 이용해서 캐시 여부 결정하고 Conditional GET 활용하며, 매번 독립적인 요청임
  
• Expose directory structure-like URIs.
• Think of a URI as a kind of self-documenting interface
• the structure of a URI should be straightforward, predictable, and easily understood
• One way to achieve this level of usability is to define directory structure-like URIs.
• http://www.myservice.org/discussion/topics/{topic
• http://www.myservice.org/discussion/2008/12/10/{topic} a.k.a http://www.myservice.org/discussion/{year}/{day}/{month}/{topic}
• Some additional guidelines
• Hide the server-side scripting technology file extensions (.jsp, .php, .asp)
• Keep everything lowercase.
• Substitute spaces with hyphens or underscores.
• Avoid query strings as much as you can.
• Instead of using the 404 Not Found code if the request URI is for a partial path, always provide a default page or resource as a response.
• Transfer XML, JavaScript Object Notation (JSON), or both.
• Common MIME types used by RESTful services
• application/json
• application/xml
• application/xhtml+xml
  

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

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