SOAP for distributed transaction

Question

I have been reading on difference between REST and SOAP. I see in many posts that SOAP is a better choice for distributed transactional resources. Please give me a practical example of SOAP being used for distributed transaction.

Answer 1

SOAP has been the main player for many years inside enterprise applications simply because there was no alternative. REST came later.

Since SOAP is a protocol it is easier to build tools around it since you know how it behaves always (i.e. as the protocol is defined). For this reason and because it's mature as technology, a lot of other specifications were build around it, to cover any uses one might have for doing something with SOAP. See a list here. There are of course some for transactional semantics also. If you use SOAP with a technology like Java or C# (which are heavyweight champions in the enterprise applications field) then you can have these transactional specifications already implemented in the framework or libraries and you just use them.

REST on the other hand is an architectural style of building applications. It's harder to limit it to a set of specifications. You can implement it in many ways. It is also going somehow against "the way of the SOAP" by staying away of creating new standards or specifications and instead just reusing the ones of the web. For this reason, there are no specs or tools to help you with transactional RESTful services. You have to build your own.

So when your application is build by self-contained web services, and these services need to cooperate on creating the applications outcome, and you need a distributed transaction to guarantee that outcome is consistent (all operations succeeding or none succeeding) then it's (more) practical to go for the technology that has the better tooling in supporting it.