Why ReST is Better - Part 5 - Self Descriptive Trampoline

In my last installment I emphasized the core difference between ReST and SOAP. ReST leverages the use of names (i.e. URIs) to enable complex interactions. Sam Ruby has a good analogy of how this works:

Have you ever played an Adventure game?  One where you walk around a world, and at each location you pick from one of n possible alternatives?

At each place you stop, there is a document which describes your choices.  Associated with each document is a scheme which helps you decipher the document.  Along the way, you may find items that you can pick up.

Some of those schemas don’t simply contains pointers, but permit form input consisting of primitive data types which you are expected to combine with the pointer to find the next location.

Sound like an unusual game?

Now, go to amazon.com.  Along the left of the page you will find a bunch of links.  Pick one.  There you will find another page with links, and perhaps a form.  Continue to either click on links or buttons that contain words like “Continue”.

Along the way you may find that you have picked up items.

Wander around this application long enough, and you may end up at the “check out”.

Question: Can you describe this application using WSDL?  Or SSDL?

Howard Smith and Peter Finger describe similar kind of behavior in their paper "Workflow is just a Pi process":

How does email work?

We send email to you, you pass the message to third parties and, through this exchange they are able to get back to us. How does this happen? By receiving email, or more specifically by receiving an email address, directly or indirectly, we acquire the capability of giving, to third parties, the capability to communicate with others linked to that email address. (Read that last part again, as it’s important.) This is what makes email work.

We give a name, in the form of an email address, to others, and this gives them the ability to communicate with yet other participants in the thread of the conversation—opening up the conversation so that it extends, over time, to involve new participants that contribute value to the process.

We thus see two examples, one for the web and another for email that reveal how useful and powerful the concept of exchanging names truly is. It's utterly surprising that SOAP adherents who claim a "deep understanding of the web" would miss this point entirely. Could it be that they are too accustomed to thinking about computing in an old and antiquated way? When you focus on the ideas of "services" you emphasize computation, however when you think about "names" then you focus on collaboration. Gone are the days when computation was the primary function of computers, today computers are used primarily for collaboration. It's just unfortunate that our Computer Science educational system continues to pump out graduates who still think like it is the former.

Okay, I hope we all have a good grasp of what we're talking about when Roy Fielding says "hypermedia is engine of application state". With ReST you can exchange representations in any form, however representations that do not embed URIs support only the most naive of protocols. To enable rich semantics collections of URIs embedded in representation need to be exchanged. That implies that the receiving client knows how to extract these embedded URIs and can know how to choose which URI to traverse. To do this, the representation itself needs to be self descriptive. Just like an anchor tag provides a reader with descriptive text, a self decriptive message does the same a machine. In fact, Google's indexer exploits the text in the html anchor tags to discern what a href location is about.

In ReST the current state and all outbound transitions are passed to the client. This analagous to a continuation where "control flow is reified". In a previous article I showed how continuations are relevant in message exchanges and workflow enactment. One can imagine a ReST server as a trampoline driving the interaction by bouncing the client process from one URI to the next. Another good analogy would be an itinerary that travels from one server to the next. This clearly is a different mind set from the static service oriented model. That model is no different from the client-server model of years past. The DNA of the web is more dynamic, it's about exchange and therefore interaction, it's about recombinant growth. This leads me to another topic worthy of exploration, that is what properties of a system support recombinant growth or rather "design for serendipity"?

To conclude, those who don't appreciate the value of process mobility are doomed to repeat the mistakes of the past.