first_page
space people space time space visitors

More REST

The infoq.com article “Give it a REST: Mark Baker on Web Services,” an interview with Mark Baker, provides me with the most articulate and summarizing understanding of REST. This article leads to an equally summarizing and articulate tutorial at xfront.com. And the primacy is that the very act of reading about REST is RESTful!

So these are what stand out to me:

  • REST is distinguished by its fixed interface. Its members are HTTP verbs, featuring GET and POST. The parameters or arguments sent to these members are URIs. The assumption here is that is this constraint that makes OOP-centric people shun REST.
  • The fundamental meaning of Representational State Transfer is that representations of remote resources change (or transfer) REST client state. This is a very formal, academic way to describe what happens when you click on a hyperlink in a Web browser.
  • Each representation changing client state has in itself the ability to change client state. So when you click on a link and get back more links to click you are chaining together n-number of changes—transferring one state to another.
  • The REST tutorial provides guidance about associating WSDL documents with any XML message sent from the client.
  • Of the REST network characteristics on slide 21 of the tutorial, labeling REST responses with “cacheable” or “non-cacheable” did not occur to me. In my recent REST-based designs, the REST client ‘decides’ to cache it does not ‘discover’ what to cache.
  • The tutorial rather surprisingly introduces XLink as a supporting technology of REST—this led me to “XLink: Who Cares?” at xml.com.
  • Equally jarring is the news that the SOAP Working Group is (was?) working on SOAP HTTP GET. What the hell is this?
  • This tutorial introduces me to Paul Prescod. In this world of podcasts and news feeds, I am, again, disturbed that I have not heard of him sooner.The ‘poetic’ message I’m getting from this reading is that organizations that support SOAP are really supporting an additional, proprietary abstraction layer that takes minimal advantage of HTTP. To “argue” on their behalf, one might say that they anticipate the demise of HTTP and look forward to another Internet. The poetry gets deeper and I remember that Microsoft was a premier supporter of SOAP—and I do not have to waste any time explaining their historical, foundational view of the Internet.

A few more RESTful links:

rasx()