First, it's helpful to define the terms a bit here, because people often have a reaction to the term "transaction" that doesn't distinguish between local and global transactions. Local transactions are used in almost every database operation today, and this is exactly the same for both Web services and RESTful applications.
The question therefore really pertains to global transactions -- those that involve more than one database, potentially on different computers -- since that's where things are very different. (I should also clarify that Web services are a technology while REST is an architectural approach, so this is going to be a bit of an apples-to-oranges comparison.)
Web services transactions (as defined in the OASIS WS-Transactions set of specifications) are intended to be compatible with existing TP infrastructures, which basically evolved from mainframe systems. The REST approach, on the other hand, evolved from the Web, which is based on an entirely different technology stream. Some of the key differences derive from the very different assumptions behind mainframe systems and Web based systems.
Mainframe systems were designed assuming an environment for resources and users under the control of a single organization. Web based systems on the other hand were designed assuming a world wide network of independent but cooperating systems under the control of different organizations and individuals. Today's corporate IT systems can be more or less divided between those developed before the Web and those developed for the Web. Systems designed for the Web have much less control over things like workload, uptime, the need to provide a good experience to users, etc. These different assumptions impact transactions because they result in very different solutions to the requirement for distributed access to shared data, or shared state.
At the technical level the biggest manifestation of the difference is in the design of the communications system. Transactional communications mechanisms that evolved from mainframe designs use persistent sessions to share state between programs. The communications protocol used in REST oriented systems, HTTP, does not support persistent sessions because they negatively impact scalability. If you are operating in a carefully controlled environment, that impact is manageable.
For compatibility with existing shared state mechanisms, Web services transactions propagate shared transactional context among participants in a global transaction so that each participant's access to shared state can be coordinated with the others. REST based transactions assume that only one party to a global transaction accesses the shared state at any given time, sort of like passing a token. The other participants have no knowledge of what's going on at another participant and their operations on shared state can't be coordinated. They are responsible only for knowing what they must do when they receive the shared state – when it's their turn. This creates is a very different design requirement for handling failure and recovery, since it cannot be automated, the trade off in additional application level design and coding pays results in a system better suited to the assumptions of the Web.
Dig Deeper on Topics Archive
Related Q&A from Eric Newcomer
ACID is used to summarize the basic properties of a transaction in the database sense of the word, not the logical "business" transaction sense. On ... Continue Reading
Are there any rules of thumb that would make one decide to do in-process interop versus Web services interop based on throughput requirements? Continue Reading
What divides mainframe level transaction processing from Java or .NET server level transaction proce
OSGi expert Eric Newcomber discuesses what divides main-frame level transaction processing from Java or .NET server level transaction processing. Continue Reading