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

<p>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.</p>

<p>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.</p>

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.