Amen! Does anybody really use the complicated SOAP standards? I don't know anybody who does. And if you do, you should think about how to make it simpler.

From Adam Bosworth's Weblog: KISS and The Mom Factor:


it is interesting to me how this focus around simplicity in the services world could carry through even to the plumbing people use. For example take so called web services. The original impetus behind XML, at least as far as I was concerned back in 1996, was a way to exchange data between programs so that a program could become a service for another program. I saw this as a very simple idea. Send me a message of type A and I'll agree to send back messages of types B, C, or D depending on your A. If the message is a simle query, send it as a URL with a query string. In the services world, this has become XML over HTTP much more than so called "web services" with their huge and complex panoply of SOAP specs and standards. Why? Because it is easy and quick. Virtually anyone can build such requests. Heck, you can test them using a browser. That's really the big thing. Anyone can play. You don't have to worry about any of the complexity of WSDL or WS-TX or WS-CO. Since most users of SOAP today don't actually use SOAP standards for reliability (too fragmented) or asynchrony (even more so) or even security (too complex), what are they getting from all this complex overhead. Well, for one, it is a lot slower. The machinery for cracking a query string in a URL is about as fast as one can imagine these days due to the need services have to be quick. The machinery for processing a SOAP request is probably over ten times as slow (that's a guess). Formatting the response, of course, doesn't actually require custom XML machinery. If you can return HTML, you can return XML. It is this sort of thinking that being at a service company engenders. How do you keep it really simple, really lightweight, and really fast. Sure, you can still support the more complex things, but the really useful things may turn out to be simplest ones.