One of the frequently asked questions about RESTful web services is how to deal with transactions. Usually, one of the following scenarios prompts this question:
A client goes through a sequence of steps with a server in a flow. The client would like to cancel the flow and undo all the changes done to the data in that flow.
A client interacts with a number of servers in a sequence to implement an application flow, and the client either wants to revert any resulting state changes or wants to record them permanently.
Transactions are often seen as a missing feature of REST and HTTP. For instance, if HTTP supports transactions, a banking server could let a client deduct some amount from one account and add it to another account within a single transaction, thus guaranteeing atomicity. Such an implementation would also improve the visibility of interactions since each HTTP request could be implemented to not modify any related resource. However, supporting transactions in distributed and decentralized web services reduces the separation of concerns between servers and clients. It also makes the application protocol stateful, thereby reducing scalability.
You want to know how to support transactions.
Provide a resource that can make atomic changes to data. Treat
uncommitted state as application state, and manage it as per Recipe 1.3. If the server
needs to allow clients to undo actions, use
POST as appropriate to make compensating ...