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 believe that would be the case of using a unique identifier generated on the client to ensure that the connection hiccup not imply in an duplicity saved by the API.

I think using a client generated GUID field along with the transfer object and ensuring that the same GUID was not reinserted again would be a simpler solution to the bank transfer matter.

Do not know about more complex scenarios, such as multiple airline ticket booking or micro architectures.

I found a paper about the subject, relating the experiences of dealing with the transaction atomicity in RESTful services.

Answer 3

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".

Answer 4

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 5

First of all transferring money is nothing that you can not do in a single resource call. The action you want to do is sending money. So you add a money transfer resource to the account of the sender.

POST: accounts/alice, new Transfer {target:"BOB", abmount:100, currency:"CHF"}.

Done. You do not need to know that this is a transaction that must be atomic etc. You just transfer money aka. send money from A to B.

---

But for the rare cases here a general solution:

If you want to do something very complex involving many resources in a defined context with a lot of restrictions that actually cross the what vs. why barrier (business vs. implementation knowledge) you need to transfer state. Since REST should be stateless you as a client need to transfer the state around.

If you transfer state you need to hide the information inside from the client. The client should not know internal information only needed by the implementation but does not carry information relevant in terms of business. If those information have no business value the state should be encrypted and a metaphor like token, pass or something need to be used.

This way one can pass internal state around and using encryption and signing the system can be still be secure and sound. Finding the right abstraction for the client why he passes around state information is something that is up to the design and architecture.

---

The real solution:

Remember REST is talking HTTP and HTTP comes with the concept of using cookies. Those cookies are often forgotten when people talk about REST API and workflows and interactions spanning multiple resources or requests.

Remember what is written in the Wikipedia about HTTP cookies:

Cookies were designed to be a reliable mechanism for websites to remember stateful information (such as items in a shopping cart) or to record the user's browsing activity (including clicking particular buttons, logging in, or recording which pages were visited by the user as far back as months or years ago).

So basically if you need to pass on state, use a cookie. It is designed for exactly the very same reason, it is HTTP and therefore it is compatible to REST by design :).

---

The better solution:

If you talk about a client performing a workflow involving multiple requests you usually talk about protocol. Every form of protocol comes with a set of preconditions for each potential step like perform step A before you can do B.

This is natural but exposing protocol to clients makes everything more complex. In order to avoid it just think what we do when we have to do complex interactions and things in the real world... . We use an Agent.

Using the Agent metaphor you can provide a resource that can perform all necessary steps for you and store the actual assignment / instructions it is acting upon in its list (so we can use POST on the agent or an 'agency').

A complex example:

Buying a house:

You need to prove your credibility (like providing your police record entries), you need to ensure financial details, you need to buy the actual house using a lawyer and a trusted third party storing the funds, verify that the house now belongs to you and add the buying stuff to your tax records etc. (just as an example, some steps may be wrong or whatever).

These steps might take several days to be completed, some can be done in parallel etc.

In order to do this, you just give the agent the task buy house like:

POST: agency.com/ { task: "buy house", target:"link:toHouse", credibilities:"IamMe"}.

Done. The agency sends you back a reference to you that you can use to see and track the status of this job and the rest is done automatically by the agents of the agency.

Think about a bug tracker for instance. Basically you report the bug and can use the bug id to check whats going on. You can even use a service to listen to changes of this resource. Mission Done.

Answer 6

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.