And take testing - you need to pull out the heavy artillery (SOAP UI is very good) to test a SOAP service. Whereas REST can be done quite easily (even more so if it's GET), from a browser or a simple python script.
Not huge issues, and if you're working on a big project it won't make a big difference. But still a PITA, in my opinion
Fair enough. I always preferred to log at the "middleware" level but I guess that's a use case.
> Whereas REST can be done quite easily (even more so if it's GET), from a browser or a simple python script.
GET for everything is a large part of what the article is advocating. Once you get into "true REST" (using PATCH/DELETE/etc., maybe content negotiation) then you quickly move out of what you can test with the browser.
As for Python that was one of the things I loved about SOAP - plug the .wsdl into suds and you can test it from your Python script and you don't even need a separate doc, you can just use Python's built-in dir() and help().
The problem is that this does not actually help much in validating data sent or received. In addition, the client side SoapFooData you might receive is unlikely to be something that you want to pass around, so you still need wrappers for most complex structures.
Working with SOAP is complex even for extremely simple APIs, and for complex ones you will end up NOT using the generated objects anyway.
Finally implementations are generally buggy and incompatible with each other. And generated code is something that should be strongly avoided.
So in short: SOAP is complex and in return you get something that's pretty much useless (generated objects)
