Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News REST and transactions?

REST and transactions?

This item in japanese

There has been a long debate about the benefits of REST versus other approaches (notably Web Services), or simply the benefits of using it for Web-based integrations. The discussions continue, but several people have begun to try to move the debate to whether or not there are certain capabilities we take for granted elsewhere that are missing in REST, or specifically in REST-over-HTTP. One of those things is distributed transactions and there has been a recent to-and-fro on the REST-discuss mailing list, triggered when Bill Burke pointed people at an implementation done on RESTeasy and asked for comments.

Pretty clean API. I want to see if Atom Links can replace some of the published URI schemes so that we can limit the number of URIs exposed by the system and give more flexibility to the system as a whole. I'm also wondering if we standardize on Link Relationships rather than data format, this may free a DTX standard from having to define a data format altogether.

This initially triggered a lively debate about whether you need ACID transactions or compensation-based transactions, with Bob Haugen (ex-Choreology and OASIS BTP) pointing out:

The basics are: 1. In the first phase, all participants update their resources provisionally (whether by state or by separate provisional resource), 2. Upon commit, all participants update their resources in their final state (or create final resources). 3. Upon abort or cancel, all participants delete their provisional resources, or mark them cancelled, or create new cancelled resources. The pattern also allows selective commits or cancels, for example for a bidding process.

There seemed to be general agreement that if you needed transactions at all then some form of extended transaction (of which compensations is a specific example) were the way to go, for the same reasons as with Web Services. Mike Amundsen added:

I prefer using the Saga model since it is an "optimistic" pattern and I find that easier to model over HTTP. On the more pragmatic side, I can model the initial interaction set w/o employing the details of the saga (implementing either 'forward compensation' or 'backward compensation' steps). I can then add the compensation work later in the implementation process (sometimes weeks or months!) without much disruption to clients or proxies, etc.

After a while Roy Fielding joined in the discussion, having said several years previously ...

This topic has come up a few times on webdav and http-wg lists. The transaction is a resource, but the relationship between it and the requested resource can be accomplished via a header field that defines each request as a sequenced resource within a hierarchical transaction. In other words, ask the server for a transaction begin, send the URI it gives the client in each request as a header field with a request number appended to it, and finally abort or commit the transaction as a final request to the transaction's URI. That's basically how I did it for the still-vapor waka protocol.

However, over the years Roy's opinions have changed, based on his experiences.

If you find yourself in need of a distributed transaction protocol, then how can you possibly say that your architecture is based on REST? I simply cannot see how you can get from one situation (of using RESTful application state on the client and hypermedia to determine all state transitions) to the next situation of needing distributed agreement of transaction semantics wherein the client has to tell the server how to manage its own resources. Most likely, the system you are thinking of is just doing CRUD operations on multiple servers. Each of those actions might be based on a RESTful architecture. When all of them are done and the client makes a final request to approve or cancel the changes, it might be interacting with a TM-style manager resource that tells all of the other services to commit the associated changes to a more persistent or public set of resources, just like a staging server might be used to prepare content prior to publication. The sum of all those actions might be equivalent to an ACID transaction. None of that matters to the REST client. As far as the client is concerned, it is only interacting with one resource at a time even when those interactions overlap asynchronously. There is no "transaction protocol" aside from whatever agreement mechanism is implemented in the back-end in accordance with the resource semantics (in a separate architecture that we don't care about here). There is no commit protocol other than the presentation of various options to the client at any given point in the application. There is no need for client-side agreement with the transaction protocol because the client is only capable of choosing from the choices provided by the server.

There was a lot of follow-up to this, with examples of where extended transaction protocols (not ACID) could and are being used in what the posters believe to be a RESTful manner. However, Bill Burke interjected that that wasn't really the point of his original post:

This was what I meant in my original post that defining and standardizing a few link relationships might simplify things a lot, both at the client resource level and resource/TM interactions.

This did seem to resonate with a several of the people on the mailing list. In fact Alexandros Marinos then pointed people at a protocol (ACID based) that he and colleagues have been working on implementing. The discussion continues, but there seems to be no clear answer to whether or not (extended) transactions really do fit in a REST world. However, it does seem conclusive that many people believe they need them for one reason or another.

Rate this Article