As a user of a SOAP API, you just have to fire up your IDE and point it to the WSDL file, describing the SOAP API for the web service you are going to use. After that, you can automagically call the API, like:
And all this has been tauted in popular IT magazines
Anyway, SOAP has a lot of problems and one of them being that it is just not a standard protocol. It is an application protocol layered on top of another application protocol (HTTP).
In the past I've written up web scrapers for a multitude of services, and I was doing a primitive form of web services. Tim O'Reilly looks at this as using the URL as a sort of command line. He coined up the term 'URLline interface' at Emerging technologies keynote speech.
I always have had a guts feeling that SOAP is too bloated. I love XML-RPC, because it is lean and mean and the most important feature for me was the fact that on the server a method was called with the correct parameters filled in and on the client I just invoked a method call that would automagically be resolved on the server side.
Last week I came across a new concept - REST - that stands for REpresentational State Transfer. It describes the standard HTTP protocol as good enough - and even better - to implement web services. It compares HTTP and the URL as something that mimics the openess of the UNIX platform. On UNIX you can pipe output from one app to the input of the other. Building complex stuff with simple application that each perform an atomic unit of work.
Anyway, I'm going to spend some time this week to read up on the ideas of REST. Maybe it will give me a clearer idea if investing time in SOAP is worthwile