3 ms·

I would say the main PITA with SOAP is the fact that all the methods exposed by a service are on the same http endpoint. So without capturing headers you don't

by namdnay 12y ago

I would say the main PITA with SOAP is the fact that all the methods exposed by a service are on the same http endpoint. So without capturing headers you don't even know what operations are being called. Take Apache logs for example - all you'll see is a load of POST calls to /MySOAPServiceEndpoint. Whereas with a nicely designed REST service, you can at least see the gist of what is happening without additional logging. 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

lmm 12y ago
> Take Apache logs for example - all you'll see is a load of POST calls to /MySOAPServiceEndpoint. Whereas with a nicely designed REST service, you can at least see the gist of what is happening without additional logging. 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().
- namdnay 12y ago
  Yes I definitely agree with your last point - one of the nice things with SOAP is the autogeneration side. Same thing with Java CXF - import your wsdl and boom you have an interface with all the right methods etc, whether on client or server side.

by namdnay 12y ago

lmm 12y ago

> Take Apache logs for example - all you'll see is a load of POST calls to /MySOAPServiceEndpoint. Whereas with a nicely designed REST service, you can at least see the gist of what is happening without additional logging. 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().

namdnay 12y ago
Yes I definitely agree with your last point - one of the nice things with SOAP is the autogeneration side. Same thing with Java CXF - import your wsdl and boom you have an interface with all the right methods etc, whether on client or server side.