Nelson Minar: "It just doesn't work. Maybe with enough effort SOAP interop could eventually be made to work. It's not such a problem if you're writing both the client and the server. But if you're publishing a server for others to use? Forget it.
The deeper problem with SOAP is strong typing. WSDL accomplishes its magic via XML Schema and strongly typed messages. But strong typing is a bad choice for loosely coupled distributed systems. The moment you need to change anything, the type signature changes and all the clients that were built to your earlier protocol spec break. And I don't just mean major semantic changes break things, but cosmetic things like accepting a 64 bit int where you use used to only accept 32 bit ints, or making a parameter optional. SOAP, in practice, is incredibly brittle. If you're building a web service for the world to use, you need to make it flexible and loose and a bit sloppy. Strong typing is the wrong choice.
The REST / HTTP+POX services typically assume that the clients will be flexible and can make sense of messages, even if they change a bit. And in practice this seems to work pretty well. My favourite API to use is the Flickr API, and my favourite client for it is 48 lines of code. It supports 100+ Flickr API methods."
2 Comments
Strong typing has nothing to do with SOAP and/or WSDL. It is a peculiarity of the implementation strategy chosen by the predominant SOAP stack implementations that there is a databinding of the SOAP message's content to a strongly typed type system. This is largely a vestige of certain early proponents of JAX-RPC who insisted that SOAP was designed for RPC and all that message passing stuff was for nerds. If the SOAP messages were processed as XML then many of the issues cited as "failings" of SOAP (though they are NOT!) would disappear (well, mostly). Frankly, having a SOAP stack that processes the XML as XML (rather than through the lens of a databinding) is really no different than HTTP/POX... it just has some well defined QoS attributes that can come in handy on occasion. SOAP1.2, even has a RESTful binding (SOAP Response MEP) which could be used when needed for such things as securing the resource representation without the need to invent one-of security schemes for each schema type.
Frankly, the whole REST v SOAP debate is moot, and it is so because it compares an architectural style (which can be applied to SOAP usage despite proclamations to the contrary) with a message format/protocol.
The flip side unfortunately is that weak typing in distributed apps give attackers plenty of room to break into your system, SQL injection, command injection, resource injection, on and on. So if we are talking about resilience to attacks, weak typing is making the problem much worse.