Well said. =0)

Now go say it on rest-discuss, where the conversation is!

Hi Arnon, It's good to see your thoughts laid out. One of the reasons for making and publishing the model was to make the argument for transactions within a RESTful architecture, so counter-arguments definitely push the discussion forward. the response may be slightly long but that's just because I am very interested :)

To begin with, I don't see you objecting to the RESTfulness of the model, which I guess is good. But that leaves open the question: Can you design a service that is fully RESTful yet does not have the properties that REST promises?

While the article targets 'transactions', you say that SAGA may be a good idea so I am not sure if your concern is with transactions or locks in particular. If it is the second, the article could be better named 'Locking is bad for REST' which may be a finer point.

Let's see your concerns one by one though:

Regarding service boundaries and transactions introducing coupling: I think you are considdering RESTful service == service with publically available (and editable) resources. While that may be the case, it is not the only case. Many servers allow users to create and manage resources. Also, who a server allows to hold locks and for how long depends on the server. It may be the case that the server trusts that specific client, for these specific resources. Put these two together, and it is easy to see that each server may allow (groups of) users to create, lock, and transact over their own resources without too many trust issues. Also, think about the shopping cart scenario. In that case each service is making their own transaction model whether they know it or not. Regarding DoS attacks, we have a timeout feature where unused locks expire after a server-designated interval. This again can be tied to the degree of trust the server has in the client. Also, the DoS argument could be made for any service that allows a processor-intensive operation to be invoked by the public (youtube video transcoding comes to mind). Yes, it does open the door if done badly, but I don't see it as an insurmountable obstacle, especially if applied to a suitable scenario.

Assuming atomicity: What about when the resources belong to the same service provider? We assume atomicity all the time when updating a resource has as a side-effect the updating of other resources. All we are doing in this regard is the capability of the user to create transaction resources, the side-effects of which are wired by the user. The atomicity assumption is not something locking has brought in.

On hindering scalability: It may be so, but if locking is deemed necessary, then the tradeoff is something the service designer has to decide. I would hate to make that choice for them. Again, having a standardised mature model for this eases the scalability constraints when compared to ad-hoc models which would be the case otherwise. As for the multi-service scenario, 2PC does have its limitations and SAGAs is probably the way to go.

Finally, you mention the overhead for those who don't want to do transactions. This overhead is actually minimal and consists of two links being included with the lockable resource. They don't have to bother with anything else. These links have been put there to comply with HATEOAS so it seems a case of 'damned if you do, damned if you don't'. However Roy says that REST does sacrifice some efficiency so this tradeoff has been decided long ago and is not something we can control. Also, in a SAGAS type model, these links and additional resources would still exist, so again I am not sure if you are criticising locking in particular or transactions in general.

IMHO the way to simplify an API is to shift the balance of immutable vs. mutable data. Transactions only need to apply to the mutable bits, so if the bulk of the operations are handled immutably with a single self contained transaction tying the knot at the end this helps with both the simplicity and the scalability of everything.

This is especially helpful when the overhead (for the software and the human) of invoking an API is high, as it is with REST (as opposed to just an object method).

This application of immutability also closely relates to the eventual consistency fad that everyone seems to be talking about without really knowing the intricate details involved.

<plug>immutability label on my blog</plug>

As long as the interaction is stateless and does not require locking resources, I think there are a number of advantages to exposing transaction-like interactions at the hypermedia level.

The biggest advantage of Saga-like patterns of classic transactions is the use of optimistic rather than pessimistic locking. I've recently been working up a hypermedia-based interaction over HTTP that includes a media type (application/saga+xml), headers (Accept-Saga, Content-Saga, Expect-Saga), and a set of expiring hyperlinks that allow clients to execute the "rollback" of the saga.

This allows any party in an HTTP interaction to act as a "saga leader", enlist other parties into the saga, verify that these parties can successfully support a saga interaction, provide process information on the current saga and even execute a complete rollback of the saga if it is within the expiry window.

Transactions don't have to be in REST? What about an application which uses REST services might need transactional behavior out of the effects of multiple disparate services owned and operated by various companies?

It's these types of applications which "there is no need for transactions" believers seem to overlook. Yes, it is harder to design a service that has reversible state transitions, but it should be possible, and having an application make multiple requests to "undo" things to make the appearance of a transaction is just silly.

If you provide a service that is meant to be a part of another system, than transactions are just part of what happens.

Do people just always use wonky worthless transactional systems or what drives all the madness of "we can't have transactions here"?