SOAP - What's the point?

Question

I mean, really, what is the point of SOAP?

Web services have been around for a while, and for a while it seemed that the terms \'SOAP\' and \'Web service\' were largely

Answer 1

The topic is well-discussed in Why is soap considered to be thick.

Answer 2

As Joel Spolsky says, give a programmer a REST URL, and they can start playing with the service right away, figuring it out.

Whereas if the service had a well specified, machine readable contract, then the programmer wouldn't have to waste any time figuring it out.

(not that WSDL/SOAP is necessarily an example of good implementation of a well specified contract, but that was the point of WSDL)

Originally, SOAP was a simple protocol which allowed you to add a header to a message, and had a standardized mapping of object instances to XML structures. Putting the handling metadata in the message simplified the client code, and meant you could very simply persist and queue messages.

I never needed the header processing details when I built SOAP services back in 2001. This was pre-WSDL, and it was then normal to use GET for getting information and queries (no different to most applications which claim to be REST; REST has more in terms of using hyperlinks for service discovery) and POST with a SOAP payload to perform actions. Those actions which created resources would return the URL of the created resource to the client, and the client could then GET the resource. I think it's the fact that WSDL made it easy to think only in terms of RPC rather than actions which create resources which made SOAP lose the plot.

Answer 3

Well it appears now that the WSI agree that SOAP no longer has a point as they have announced they will cease to exist as an independent entity.

Interesting article about the announcement and some commentary here: http://blogs.computerworlduk.com/simon-says/2010/11/the-end-of-the-road-for-web-services/index.htm

Edited to be completely accurate in response to John Saunders.

Answer 4

While doing some research to understand some of the answers here (especially John Saunders') I found this post http://harmful.cat-v.org/software/xml/soap/simple SOAP is more insane than I thought...

Answer 5

Am I wrong?

"You're not wrong, Walter, you're just... :)"

Are there any good reasons to ever choose SOAP over REST?

SOAP, to my understanding adheres to a contract, thus can be type checked.

Answer 6

I find that SOAP fits in most appropriately when there is a high probability that a service will be consumed by corporate off the shelf (COTS) software. Because of the well specified contract employed by SOAP/WSDL most COTS packages have built in functionality for consuming such services. This can make it easy for BPM/workflow tools etc. to simply consume defined services without customization. Beyond that service use case REST tends to be my goto web service implementation for applications.