John Calcote in RESTful Transactions:
It’s clear that creating proper RESTful transaction semantics is a tricky problem.
Yes, only when you try to replicate connection-oriented interactions over HTTP. The solution to this problem is simple – "don't do it".
HTTP is not a data manipulation API. Transactions come into picture only when you treat HTTP as a data manipulation API, which consequently leaks server-level abstractions to clients. Being RESTful does not mean that the server should leak all data manipulation rules and integrity constraints to its clients.
{ 5 comments… read them below or add one }
That’s a nice, but useless sentiment. The world is all about using http for web services these days. Bank account management is only one of an entire category of web services that people are trying to implement on the programmable web. I will agree with you on one point, however. The web *is* about data rendering. And an atomic transaction on one or more accounts is a bit of data that benefits greatly from proper rendering – that is from proper REpresentational State Transfer. But what you’re implying is that a bank account web service should be limited to merely displaying these transactions – if a customer wants to actually create them, he has to use another mechanism, such as walking down to the bank. This limitation doesn’t work in the real world, does it?
The web is not about data rendering. This is an unfortunate consequence of some trying to equate CRUD with HTTP. Check some of the Roy Fielding’s posts on this topic. I
The key point here is that, the server understands the semantics of what a transaction means, and there is no need to expose these semantics to clients.
The best way to solve problems like this is to submit a request to the server to do the transfer. In the real world, a bank transfer does not just mean (Acct1 – sum) and (Acct2 + sum). This may involve several back-end processes, and a client should not be able to control those directly.
HTTP servers are, afterall, servers in distributed apps. So, the same principles of loose coupling and separation concerns do apply.
Yes, I’ve since concluded this myself. I think the general consensus among the purist RESTful web service community is that there’s no such thing as a general purpose RESTful transaction service. Rather, REST seems to promote the exposure of the highest level services provides by a web service. I actually tend to find this more palatable anyway. :)
Well, there’s different types of transactions…I don’t see why a compensation engine wouldn’t be restful as all you’re really doing is coordinating work.
Bill – there is nothing wrong in a compensation engine as long as it is hidden behind a resource. Letting clients know about a “compensation engine” is a leaky abstraction. Clients should see application specific concepts like “canceling an order” but not “run a compensating transaction”.
If you are building products, build an engine for compensation, but let app developers wrap such an engine with resources.