Ask YC: How big of a failure is SOAP?

SOAP was engineered by enterprise companies for enterprise applications. It came form the same thought train as COM/DCOM, CORBA, etc.,. It is still a major player in the enterprise world. You wont see many B2B apps that don't use SOAP or some other XML payload. I have used SOAP extensively in PHP and C#, together even. The support is there for it if you look. Java actually has good support for SOAP, if not the best (<a href="http://java.sun.com/webservices/" rel="nofollow">http://java.sun.com/webservices/</a> <a href="http://ws.apache.org/axis/" rel="nofollow">http://ws.apache.org/axis/</a>).<p>Most of the haters on SOAP and other thick WS technologies are people trying to do simple AJAX type message transfers. SOAP is a little heavy for that. But when you try passing messages between multiple systems in multiple languages, it becomes the obvious solution. As far as the following response goes... "allow me to put it this way: 1k of text to get a 2 or 3 digit temperature from a weather service." SOAP stacks will automatically parse that 2-3 digit number into the correct data type for the platform/language you are using. Now say instead of a 2-3 digit number you passed an entire object or data structure. Would it be easier to role your own parser or have the SOAP stack automatically marshal it for you?<p>Added to this, when you use the full set of SOAP technologies including WSDL and XSD, you also have data validation and to some extent, documentation. This is what JSON and the likes lack. If you provide a WSDL I can look at it and usually use a tool to automatically generate all the data types and interfaces needed (ie. wsdl in .Net). You point me at a JSON interface and I have no such luxury. I wont know what data to expect until you write documentation for it. Further neither of us would know if each others messages were valid without some kind of custom validator.<p>Also SOAP is transport layer agnostic. If you use HTTP you can take advantage of any compression the underlying platform supports. Apache's Axis and Perl's SOAP::Lite both support HTTP compression in their SOAP stacks. I am aware of ways to enable it in .Net as well.<p>Advances in computing power and network resources are making SOAP a more viable option, not less. It comes down to using the right tool for the job and REST is viable in some applications, but SOAP is as well. SOAP's life span will be at least as long as COM or CORBA. They haven't completely died yet either...

allow me to put it this way: 1k of text to get a 2 or 3 digit temperature from a weather service.

I've been working with XML-RPC (predecessor to SOAP) over the past few days and it's much less painful than SOAP. It only takes a couple lines of (python) code to get a client running functions on a remote server, without having to know what is going on below.

Java does have a pretty good SOAP stack, namely Axis.<p>The claim of early SOAP advocates was that it would enable more loosely coupled, 'be liberal what you accept and conservative about what you generate' type services, especially when compared to older technologies like CORBA.<p>Unfortunately, the approach taken to this was to add more and more metadata, and the outcome has been, well, lousy interop because implementations disagree over the metadata. The standards and the stacks have been designed and tested based on hypothetical use cases rather than having arisen out of real world uses and I think we all know how well that approach works out.<p>It actually turns out that there are some things that SOAP is good for - for example, you want to create a service that can only be called with digitally signed, timestamped requests from known clients you trust, well, you can do that with SOAP pretty easily compared to rolling your own. But unless you are doing B2B, it's unlikely you have any need to do that - and even if you did you will probably find yourself mandating a particular stack for both client and server to make it work. So much for loose coupling - SOAP ironically turns out to be great for <i>tightly coupled</i> SOA.

Paul Prescod has written some very thoughtful articles on REST versus SOAP. See:<p><pre><code> http://www.prescod.net/rest/ </code></pre> in particular:<p><pre><code> http://www.prescod.net/rest/rest_vs_soap_overview/ </code></pre> SOAP is indeed on the way out but not quite for the reasons most people say. It's not just due to the overhead, or even the incompatibilities. These are symptoms of the fact that it's solving the wrong problem. SOAP is a way to tear your program apart and put half of it on one machine and half of it on another. REST is a design strategy that requires the absolute minimum of coordination, thus it scales somewhat better, like the web itself.<p>That said, magical RPC-injection protocols like SOAP often work really well for quick and dirty apps within a single organization.

I've used SOAP at work with great success. We map sql select queries from the input XML and use the web service simply as a language independent (text-based), read-only database (we only allow select). The XML let's us control all queries run on the database and provides more than enough flexibility for generating a flexible where clause for filtering.<p>The platform independence is huge for obvious reasons. The XML based querying is huge because now the data model is totally hidden from our users. We just work from what they're asking for.

Interoperability is a mess. From the server side, no matter how long you chip away at it, there always seems to be another client library, or another version of a client library, that will bork.<p>However, provided your server can talk to it at all, Microsoft's toolchain works really, really well for anybody writing a client. If you are providing a web service and want .NET developers to be interested, you owe it to yourself and them to provide a SOAP interface.

Huge, epic fail. I work with some extremely smart developers. When ever a task involving SOAP comes up, faces drop around the room. RESTful APIs (be they XML or JSON, the latter often preferable) are far, far easier to consume.<p>I don't have a link, but I remember hearing Jeff Barr from Amazon Web Services claim that the services they provided in both REST and SOAP saw an order of magnitude traffic to the REST interface.

I can't speak to java's support for consuming web services, but I've written plenty of code that consumes java web services from .net. So far most of the problems I've encountered were the result of the partner (using java) publishing an invalid or incorrect wsdl. A little hand editing is all it takes to generate functioning proxy classes.

My personal preference is REST and I hope SOAP will slowly disappear because I've never felt comfortable using it.

Java for soap is quite extensive and generally works extremely well. We have used it in many places with good results. The only major problem is, as you discovered, trying to deal with discrepancies when calling complex services designed specifically for .NET.

We are using a simple alternative that we call 'Query Style calls with JSON Responses' ... <a href="http://code.google.com/p/polarrose-wsf/" rel="nofollow">http://code.google.com/p/polarrose-wsf/</a>

<a href="http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/" rel="nofollow">http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-...</a>