I wish this article would describe why to use SOAP. I was under the impression that SOAP was a fairly dead technology. Particularly as we move to PUSH services with PubSubHub or the RSS version (I forget what it's called).
SOAP is dead for good reason. Its an overcomplicated POS. I will pretty much refuse (unless there is no other alternative) to use a web service that only supports SOAP.
My conspiracy theory regarding SOAP is that major tool vendors support it because you need a complicated and expensive tool to design a SOAP service.
..because you need a complicated and expensive tool to design a SOAP service...
huh? Don't think so. Can you please give some more info about your opinion? My SOAP services was always easier to implement than others like XML-RPC for example. Never found anything complicated about SOAP.
> Can you please give some more info about your opinion?
Visual Studio web services generates some befuddling code, at least when I last used it about 5 years ago. Maybe things are better now?
Also, it is difficult to implement a good SOAP library. For example, in the Ruby world, there is soap4r, which has difficulties talking to EJB SOAP and .NET SOAP, which have different conventions. I had to interop with a .NET soap service, and it was pretty painful.
> My SOAP services was always easier to implement than others like XML-RPC for example. Never found anything complicated about SOAP.
Good for you. You must be smart.
I find REST much easier and straightforward. I never bothered learning the SOAP protocol, which doesn't make me very sad for some reason.
Besides if you do need something like SOAP but without the unnecessary overcomplications you always have XML-RPC (http://www.xmlrpc.com/) which I use a lot.
Seriously, a long time ago I implemented SOAP for a commercial J2EE product, and used SOAP, but I don't use it anymore. Good riddance - REST style is easier to support and use.
I just wrote a book for APress on Web 3.0, and my pitch was that it is more about publishing and reusing data.
