4 ms·

I'd like to know too. There are a lot of people here rubbishing SOAP without explaining why. I've consumed, simultaneously with hundreds of other developers f

by lusr 14y ago

I'd like to know too. There are a lot of people here rubbishing SOAP without explaining why. I've consumed, simultaneously with hundreds of other developers from disparate teams, 100s of SOAP services across a number of financial institutions and any issues I ran into had nothing to do with SOAP. Generating code with SvcUtil is great and does what it's supposed to - and nothing stops you from refining it or writing your own service clients. I don't need to run service calls from the command line - I have version controlled integration tests that I right click on and select "run", as should every major consumer of serious services. I don't believe SOAP web services are always the way to go (I've never used any in my personal projects, preferring my own web API and/or a service bus), but that doesn't mean it's not suitable for other problems. What's often missing from these debates is defining what environment you're operating in (legacy and dependant systems/platforms/interfaces, network architecture, how much architectural control you have, user load, number of developers, number of teams, release cycles, politics [what was the last big budget item that was purchased to solve the current problem], timelines etc.). Once you start identifying the environment details, some of the simplistic unqualified suggestions people make in these debates seem naive and ridiculous.

mythz 14y ago
SOAP is fragile, bloated and slow. It goes against what the very essence of a service should be, i.e. to expose functionality in as accessible and inter-operable way as possible. The higher up the WS-* stack you go, the less supported it becomes - eventually only the Big Enterprise frameworks from MS and IBM support the complete WS-* stack. WSDLs promote code-gen and as different SOAP frameworks have varying levels of WSDL support, you often end up with broken + ugly code-gen when trying to consume from different SOAP stacks. SOAP is also a brittle format where even a small namespace change can break the entire request, this makes versioning (a core part of evolving services) extremely difficult. I generally prefer clean HTTP APIs with Cool URI's and JSON which is a much faster, smaller, more versionable and tolerant format that provides a better programmatic fit than SOAP/XML: http://www.infoq.com/presentations/Heretical-Open-Source http://www.infoq.com/presentations/Heretical-Open-Source

by lusr 14y ago

mythz 14y ago

SOAP is fragile, bloated and slow. It goes against what the very essence of a service should be, i.e. to expose functionality in as accessible and inter-operable way as possible. The higher up the WS-* stack you go, the less supported it becomes - eventually only the Big Enterprise frameworks from MS and IBM support the complete WS-* stack. WSDLs promote code-gen and as different SOAP frameworks have varying levels of WSDL support, you often end up with broken + ugly code-gen when trying to consume from different SOAP stacks. SOAP is also a brittle format where even a small namespace change can break the entire request, this makes versioning (a core part of evolving services) extremely difficult. I generally prefer clean HTTP APIs with Cool URI's and JSON which is a much faster, smaller, more versionable and tolerant format that provides a better programmatic fit than SOAP/XML: http://www.infoq.com/presentations/Heretical-Open-Source http://www.infoq.com/presentations/Heretical-Open-Source