The model that you expose as a group of RESTful resources need not be the same as the model that the database uses. For example, you can use RESTful manipulation to build up a “change description” resource (local to the user's session) that is then applied to the database in one commit. The change description is complex, but there are no problems with dirty writes because all the user is changing a private world until they choose that they're going to commit to it.
If you think of a web-based model (useful with REST!) then this is like filling out a complicated order form in multiple stages. The company from which you are buying happily lets you fill out the form, storing values as necessary, but doesn't commit to actually fulfilling the order and charging your credit card until you say that it is all ready to go. I'm sure you can apply the same principle to other complex modifications.
One key thing though; if the commitment is not idempotent (i.e., if you commit it twice, different things happen) it must be a POST. That's probably a good idea in your scenario anyway, since I'd guess you want to remove the “building up an action description” resource on successful POSTing. (Yes, we'd still be following the “web form” model.)
I do think you want to carefully consider the complexity of your models though. It's a useful exercise to make things as simple as possible (no simpler though) where “simple” involves keeping the number of concepts down. If you have lots of things, but they all work exactly the same way, they're actually pretty simple. (Increasing the number of address lines in a customer record doesn't really increase the complexity very much.) The good thing about REST is that it uses very few concepts, and they're concepts that lots of people are familiar with from the web.
