Transactions in REST?

Question

I'm wondering how you'd implement the following use-case in REST. Is it even possible to do without compromising the conceptual model?

Read or update multiple resources within the scope of a single transaction. For example, transfer $100 from Bob's bank account into John's account.

As far as I can tell, the only way to implement this is by cheating. You could POST to the resource associated with either John or Bob and carry out the entire operation using a single transaction. As far as I'm concerned this breaks the REST architecture because you're essentially tunneling an RPC call through POST instead of really operating on individual resources.

Answer 1

You'd have to roll your own "transaction id" type of tx management. So it would be 4 calls:

http://service/transaction (some sort of tx request)
http://service/bankaccount/bob (give tx id)
http://service/bankaccount/john (give tx id)
http://service/transaction (request to commit)

You'd have to handle the storing of the actions in a DB (if load balanced) or in memory or such, then handling commit, rollback, timeout.

Not really a RESTful day in the park.

Answer 2

I guess you could include the TAN in the URL/resource:

1. PUT /transaction to get the ID (e.g. "1")
2. [PUT, GET, POST, whatever] /1/account/bob
3. [PUT, GET, POST, whatever] /1/account/bill
4. DELETE /transaction with ID 1

Just an idea.

Answer 3

Consider a RESTful shopping basket scenario. The shopping basket is conceptually your transaction wrapper. In the same way that you can add multiple items to a shopping basket and then submit that basket to process the order, you can add Bob's account entry to the transaction wrapper and then Bill's account entry to the wrapper. When all the pieces are in place then you can POST/PUT the transaction wrapper with all the component pieces.

Answer 4

I think that in this case it is totally acceptable to break the pure theory of REST in this situation. In any case, I don't think there is anything actually in REST that says you can't touch dependent objects in business cases that require it.

I really think it's not worth the extra hoops you would jump through to create a custom transaction manager, when you could just leverage the database to do it.

Answer 5

Vielleicht ist RETRO (A (hopefully) RESTful Transaction Model) interessant.

Answer 6

In the simple case (without distributed resources), you could consider the transaction as a resource, where the act of creating it attains the end objective.

So, to transfer between <url-base>/account/a and <url-base>/account/b, you could post the following to <url-base>/transfer.

<transfer>
    <from><url-base>/account/a</from>
    <to><url-base>/account/b</to>
    <amount>50</amount>
</transfer>

This would create a new transfer resource and return the new url of the transfer - for example <url-base>/transfer/256.

At the moment of successful post, then, the 'real' transaction is carried out on the server, and the amount removed from one account and added to another.

This, however, doesn't cover a distributed transaction (if, say 'a' is held at one bank behind one service, and 'b' is held at another bank behind another service) - other than to say "try to phrase all operations in ways that don't require distributed transactions".