Guilhermesilveira's Blog

as random as it gets

Transactions do not exist in a Restful world…

with 6 comments

Due to the last posts on infoq related to Restfulie, my work at Caelum Objects involved a presentation at one client, “Beginning a REST initiative” (based on Ian’s work) and the question came up: “but how do I control transactions without a custom software stack to help me?”

The answer was, “you do not need to”.

Restwiki has an old entry on how to implement transaction support through http using some non-standard http headers.

The idea was not new, as Roy Fielding mentioned on an old mail that this extra http header could be a solution and later seemed to change his mind about it, according to an infoq news.

In practice most ideas are based on a transaction being a resource named “Transaction”: an idea heavily based on HTTP and URIs, but forgetting about HATEOAS – again.

In the human web, how does one buys some products? Every product is added to the shopping basket, which then generates the order. Does the user creates a transaction before processing his order?

The human being behing the computer did not create a transaction: the browser is even unaware of that concept, but hyperlinks given by the server guided the client through this “transaction”. In this case, where the typical “REST” solution would create a “Transaction” resource and use the non-standard header to support it, a Restfulie one creates a shopping basket:

Typical “REST” approach Restfulie
sequence POST /transaction
POST /product *
POST /product *
POST /basket
POST /basket/:id/product
POST /basket/:id/product
commit POST /transaction/commit * PUT /basket/:id/payment
rollback DELETE /transaction/ * DELETE /basket/:id

* with non-standard http header

The standard way of thinking about transactions is to not use HATEOAS and believe that transactions are resources by themselves. Transactions are not resources, but a tool to implement ACID in your (i.e.) databases, not in a web system.

In our example, an order creation maps to internal transactions. In a bank example, a Transfer resource would map to the internal transaction.

By renaming the “transaction” to the real objective of that transaction, one can better map meaningful URI’s to resources.

Note that these are only the advantages of valuing the use of URIs over non-standard http headers (manifest hint?): there is no loss of visibility to layers between the client and the server.

But now one might argue that there are too many entry points. Actually, both implementations contain the same number of “entry” points if there is no hypermedia support: 4. Too many entry points should not be called “entry” points. (entry-hell pattern?)

But do we, in the human web, type in URIs as we go further with our online “transaction”? Do we type in URIs as we do a two-step flight and hotel booking process?

If the entry point POST /basket answers with a:


Header
Location: http://caelumobjects.com/basket/5
Content
<basket>
<link rel="products" href="http://caelumobjects.com/basket/5/products" />
<link rel="coupon" href="http://caelumobjects.com/basket/5/coupon" />
<link rel="pay" href="http://caelumobjects.com/basket/5/payment" />
<link rel="cancel" href="http://caelumobjects.com/basket/5" />
</basket>

Note that our basket – our transaction’s meaning – contains hints on how to operate with it and its relations pretty much in the same way that it would do in the human web: dynamically generated links that allows the server to guide the client throughout the process, eliminating the need to extra “entry-points”.

In a hotel and flight booking system, the booking POST result could be represented as:


Header
Location: http://caelumobjects.com/booking/5
Content
<booking>
<link rel="flights" href="http://caelumobjects.com/booking/5/flights" />
<link rel="hotels" href="http://caelumobjects.com/booking/5/hotels" />
<link rel="pay" href="http://caelumobjects.com/booking/5/payment" />
<link rel="cancel" href="http://caelumobjects.com/booking/5" />
</booking>

Note how the first idea on implementing transactions evolved. From a custom header which interferes with visibility and creates the need for custom built clients and layers to understand this instruction, with no server guidance at all to a system where there is no need to customize your client api or layers and the server guides the user flow through hypermedia, maturing your system.

Transactions should not be called “transactions”. The basket or transfer resource are examples of that: they are typical server side implemented transactions that should be actual resources.

Our basket (and thus transfer) seems to match Roy’s comment at that time:

  • “As far as the client is concerned, it is only interacting with one resource at a time even when those interactions overlap asynchronously.”: the basket or the transfer
  • “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).”: you add products to the list of products form that basket, add some coupons and so on
  • “There is no commit protocol other than the presentation of various options to the client at any given point in the application.”: hateoas
  • “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.”: transaction protocol? no transaction protocol here, just a simple resource handling

Restfulie – as many other rest frameworks -already support the first step (running away from the custom header), but goes further when being “hypermedia centric”, it allows the developer to implement it without any effort.

Being opiniated and forcing the adoption of hypermedia as a way to guide or clients through out our processes might be one step ahead into more web (rest in this case?) friendly world as Ryan Riley pointed out.

HATEOAS, HTTP and URIs allow you to eliminate the concept of transaction management (and web transaction managers) from your systems as we usually think of them. There are two steps to follow:

1. there are no transactions
2. let the server guide you, do not try to guide him with multiple entry points

Advertisements

Written by guilhermesilveira

December 17, 2009 at 9:00 am

6 Responses

Subscribe to comments with RSS.

  1. Hi Guilherme,

    Are you aware of RETRO? (http://tinyurl.com/resttrans) YOu could call it RESTful Transactions guided via Hypermedia. I would be interested to hear your take on it.

    Alexandros

    December 17, 2009 at 8:15 pm

  2. […] Transactions do not exist in a Restful world… […]

  3. Hi Guilherme. You should look at what the JBossTS team is doing around this. It’s now part of the work Bill Burke is doing. The Web does not obviate the need for transactions, it just changes the way in which they are used and the precise definition of “transaction” (2PC or not 2PC, for instance.)

    Mark Little

    December 19, 2009 at 7:26 pm

  4. Hello Alexandros, Mark,

    I have read RETRO’s documentation… it adds a lot of support to transaction-aware clients. I believe those are probably different paths which provide ACID benefits over the web. The API seems hypermedia driven and resource based… nice.

    Mark has also pointed out to jboss web services transaction support.
    I could not find on the web site something related to JAX-RS+transactions, is it supported by JBossTS in the web services part?

    Regards

    guilhermesilveira

    December 20, 2009 at 2:12 pm

  5. Hi Guilherme. There’s a draft of the specification in the projects link down the left hand side of the JBossTS site (www.jboss.org/jbosstm) and I think Bill has posted an update to the REST-* site he maintains.

    Mark Little

    December 20, 2009 at 4:05 pm

  6. I would say not only “You don’t need to” but transaction are really harmful in distributed systems what REST (and erm… SOA) is all about. I’m yet to see single, interoperable and working WS-TX/WS-Coordination implementation in real-life scenarios. On the other hand – there actually plenty of critical systems which actually live without transactions and doing well. Do Amazon, PayPal or Visa use distributed transactions? At the same time they’re doing hundred thousands of ‘transactions’ every day.

    Artur Karazniewicz

    December 26, 2009 at 9:03 am


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: