SOAP sucks

I have no idea who James Turner is (I probably should), but in his blog posting on O'Reilly Radar he mentions SOAP at the top of his list of the worst technologies of the last decade. Obviously this Turner fellow and I have something in common.

SOAP is indeed horrible. Primarily because it inherits much of the same madness that seems to be so ever-present in the XML world.

Given the fact that the XML world has had a decade to shape up, it is nothing short of shameful that XML technologies still are such a sad sight. I have yet to find a single XML related technology that does not suck in one way or another. Some of the people behind XML tools are part of the problem too. Not too long ago I wasted at least one full day on an XML library only to find that the root cause of the problems I was experiencing was the vanity of the author.

(I am not going to name him, although by willfully causing his library not to be usable within OSGi without modification, that he insists should not be done for reasons of pure vanity, he would certainly deserve being ridiculed)

And I am talking about really basic stuff here -- the sort of libraries that are supposed to make up the foundations of other technologies. How can I be enthusiastic about XML when the foundations are so rotten to the core I have to hold my nose when using them?

No kidding: I have been unable to find a single library, tool or protocol stack based on XML that is clean, clear, performant and free of quirks and unpleasant surprises. I would love nothing more than someone who actually bothers to do more than superficial tinkering to prove me wrong. Seriously, if you have it in you: prove me wrong.

But back to SOAP. As a mechanism for exposing APIs and doing remote calls, SOAP is pitiful. The interface definitions are needlessly verbose, the specifications have ambiguities, the tools are pathetic and when you do succeed in making the whole thing work, the performance is just terrible. You have to be blind and/or dumb not to want to improve on this significantly. Seriously, there is no better way of putting it and I fear that the most common reason is that most programmers aren't really serious enough about what they do to know or even care that the whole SOAP thing is pessimal.

I wish Google would open source their RPC mechanism. They have already open sourced Protocol Buffers, which are a big step forward, but which are a bit useless without the rest of the stack. To date, the stuff Google uses internally built on protobuffers is the only RPC mechanism I have seen that is practical, performant and fairly simple to use. No it isn't perfect, but it is reasonably robust and usable. SOAP, simply put, isn't.


  1. I'm currently torturing myself by attempting to interface with a vendor's SOAP API. The application feels like it used to be written in COM, was then ported to .NET at the last minute, and right before release, some engineer pressed the button in Visual Studio to turn a class's methods into WSDL bindings.

    Unfortunately, I cannot get any variation of Java SOAP stacks to work properly with this vendor app. The vendor's supported solution is "Don't use Java; we know the examples in the Web Services Programmer's Guide don't work. C#, Visual Basic, or C++ are the only supported languages." The main issue is that submitting large binary files to a SOAP method call just doesn't work from anything except a Microsoft .NET SOAP stack.

    My current solution is a small C# library that calls the vendor's SOAP API. I then expose a reasonable interface from C# that I can access from the desired client program. (Pretty much any interface will work; I'm using plain old HTTP.)

    In effect, the vendor makes customers write their own client libraries.

    The problem I am trying to solve is taking a document and submitting into the vendor's system. The irony is that this is the exact problem SOAP was supposed to solve: exchanging a document with a well-defined format between two systems.

  2. @Joshua: the real tragedy is that these things do not get better. SOAP was a PITA 6 years ago and it is a PITA now. There are no real improvements taking place in the SOAP-based web services world.

    On a related note: