Most illustrations of the hypertext constraint (aka Hypermedia As The Engine of Application State) focus on managing application flows using links. In this approach, the server describes the flow using links, and clients, by interpreting link relations follow the links. While such an approach is useful for illustrative purposes, baking all the flow assumptions into hypermedia is easier said than done. Not every scenario could benefit from such application of the hypertext constraint. It could even be counter-productive in situations that need to leave the flow details to clients. Mashups are great examples.
I find it much more compelling to use hypermedia to encode certain implementation details such as concurrency control, security, and even transactions that can not and must not be leaked to clients . See RESTful Web Services Cookbook for details.
Here is an example that illustrates the title of this post.
<cart> <!-- some stuff here --> <link rel="http://ex.org/rel/abort" href="http://ex.org/cart/cancel;token=987654321"/> <link rel="http://ex.org/rel/add-more" href="http://ex.org/cart/add;token=987654321"/> <link rel="http://ex.org/rel/buy" href="http://ex.org/cart/buy;token=987654321"/> </cart>
The URIs in this example are opaque to the client, but you can describe/document their semantics via link relations. These URIs let the client do things that are typically expected in a transactional application, such as aborting, saving, updating etc.
If you are searching for transaction support in HTTP and REST and are disappointed about not finding any support, you may not be looking at the right things. The hypertext is your transaction engine.