REST as a Object Model

공휴일이라 집에서 쉬다가 REST 가 어떤건지 궁금해져서 문서를 읽어보기 시작했다. 표기법의 정리인 것으로 느껴졌다. 저자는 아니라고 주장하지만(아니라고 주장하는 것은 아니고, 혼동을 방지하기 위해서라고 했던거 같다), REST는 Web distributed persistant object model.. 이라고 불리는게 마땅할 듯 하다. 단지 표기법의 정리로 폄하하는 것이 아니고, C에서 사용되던 function(object, arg1, arg2) 형태의 객체지향이, C++에서 object.function(arg1, arg2) 형태의 표기법으로 바뀐것과 마찬가지의 훌륭한 대안이라는 것이다.

뭔소린지 정리하기 위해 그림을 한장 그려 보았다.

Rest as a Object Model

위의 그림에서 볼 수 있듯이, remote(server)의 데이터베이스에 존재하는 객체에 대한 reference를 url로 할 수 있도록 했다는 것이다. 그리고 그 url을 기반으로 local(client)쪽에서 해당 객체에 대한 cache를 관리할 수 있게 된 것이다. REST가 어느정도 자리를 잡아가기 시작하면 그 framework도 정리가 될텐데 위의 그림과 같은 형태가 되지 않을까 하는 생각이 든다.
결국은 다시 skeleton/stub을 만드는 방법으로 돌아갈 것이라는 얘기이다. XRPC에서 한번 그랬고, 객체지향으로의 전환 이후에 Corba에서 한번 더 그랬던 것처럼 말이다.
기존의 SOAP의 문제점은(REST에서 주장하는), body에 object에 대한 reference가 담기기 때문에 proxy를 사용하기 힘들다는 것이다.

다음은 위키피디아에 정리되어 있는 REST의 특징이다.

• Application state and functionality are divided into resources
• Every resource is uniquely addressable using a universal syntax for use in hypermedia links
• All resources share a uniform interface for the transfer of state between client and resource, consisting of
• A constrained set of well-defined operations
• A constrained set of content types, optionally supporting code-on-demand
• A protocol that is:
• Client/Server
• Stateless
• Cacheable
• Layered

첫번째와 두번째 항목이, resource라는 이름으로 객체를 정의하고 각각의 객체는 url로 표기된다는 것을 말하고, 세번째 항목이 각 리소스는 잘정의된 연산(methods)를 가지며, return 값에 대한 type(content type)을 가진다는 것을 말한다.
마지막 항목에 프로토콜에 대한 제한을 두는데, 그것은 중간에 proxy가 contents를 까볼 필요 없이 잘 작동하게 하기 위한 제한이다.



Ruby on Rails가 일부분은 stub/skeleton을 생성하는 형태로 작동하지만, 아직은.. 갈길이 많이 남은 듯 하다. 그럼 누가 그 stub/skeleton 의 framework을 만들어 낼지, 기다려 봐야겠다.