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

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.