Most illustrations of the hypertext constraint (aka Hypermedia As The Engine of Application State) focus on managing application flows using links. In this approach, the server describes the flow using links, and clients, by interpreting link relations follow the links. While such an approach is useful for illustrative purposes, baking all the flow assumptions into hypermedia is easier said than done. Not every scenario could benefit from such application of the hypertext constraint. It could even be counter-productive in situations that need to leave the flow details to clients. Mashups are great examples.
I find it much more compelling to use hypermedia to encode certain implementation details such as concurrency control, security, and even transactions that can not and must not be leaked to clients . See RESTful Web Services Cookbook for details.
Here is an example that illustrates the title of this post.
<cart> <!-- some stuff here --> <link rel="http://ex.org/rel/abort" href="http://ex.org/cart/cancel;token=987654321"/> <link rel="http://ex.org/rel/add-more" href="http://ex.org/cart/add;token=987654321"/> <link rel="http://ex.org/rel/buy" href="http://ex.org/cart/buy;token=987654321"/> </cart>
The URIs in this example are opaque to the client, but you can describe/document their semantics via link relations. These URIs let the client do things that are typically expected in a transactional application, such as aborting, saving, updating etc.
If you are searching for transaction support in HTTP and REST and are disappointed about not finding any support, you may not be looking at the right things. The hypertext is your transaction engine.
{ 10 comments… read them below or add one }
“I find it much more compelling to use hypermedia to encode certain implementation details into links without revealing what they mean.”
not sure i understand the appeal for hiding.
Clarified the text.
i understand the clarification, now.
so what data regarding transactions might you encode in a link that should not be leaked to the client?
The fact that there is a transaction is an implementation detail in itself. Essentially the link represents the state of the transaction in an opaque manner, and may contain identifiers, security tokens and other validators.
” Essentially the link represents the state of the transaction in an opaque manner, and may contain identifiers, security tokens and other validators.”
no disagreement here as i’ve used the same approach in my example.
Hello Subbu!
Nice (and short) description! I believe it goes along with what I mentioned on “transaction do not exist in a restful world”…. its a matter of thinking about your semantics and hypermedia instead of abstract transactions concepts: http://guilhermesilveira.wordpress.com/2009/12/17/transactions-do-not-exist-in-a-restfulie-world
Nice post…
Guilherme
Thanks for pointing out to your post.
Subbu, when you have one client dealing with one service, I believe you can hide the fact that a transaction is occurring (whether this be an acid or compensating tx isn’t important, IMO). On the other hand, if a client is coordinating work between different services, the client has to be aware that coordination is happening especially if the client is coordinating totally disparate, isolated, standalone services/resources. Think of a client integrating between a Purchase Order, Inventory, and Billing system. All standalone and unaware of one another.
Coordination itself can become non-trivial especially when you factor in long running (days, weeks) interactions, crashes, and recovery. They become even more complicated when you have to guarantee that certain interactions will happen. This is why I believe there is a place for generic middleware services that handle coordination in the RESTful world. (And why REST-* was created by us (rest-star.org)). BTW, I outlined my ideas and directions here:
http://bill.burkecentral.com/2009/09/21/credit-cards-transactions-and-rest/
I think links and other RESTful properties can hide a lot of the implementation details and give a lot of flexibility to both the application developer and generic service providers (like a TM or workflowmanager). For example, Mike Amundsen introduced me to the token idea for a problem I had with acknowledgement within REST-* messaging. It worked beautifully to hide implementation details and make the overall service much simpler.
BTW, we need more engineers like you and Mike rather than the priests and acolytes that permeate the REST community. I’m really looking forward to your book.
Bill – for cases that involve coordination between several servers, I think it is better to designate some resource one of those servers (or a new one) act as a facade between those other servers. Then that resource is free to use an appropriate technology to coordinate the unit of work (the technology may be classical 2PC or some sophisticated engine). That way you get the best of both worlds – clients and servers use HTTP for what it is good for and the facade and the rest of the servers use whatever transaction/coordination engine.
By the way, use of one-time tokens/URIs is a one of the fundamental and recurring patterns that I used to the book. Once we accept the notion that one resource can have several URIs, and that those URIs may be ephemeral opens up lots of new avenues open up. This idea is not new – it is very commonly used for security (hint: nonce).
Subbu – You’ve used some of these “classical” distributed technologies to build some of these facades. You’re happy with how they work and used? I’m not… I think REST really has the potential to shine in this space.
{ 1 trackback }