Screaming Penguin - Source Does Matter

The parable itself as noted on TSS is brilliant. Very creative and very funny, props.

However I still do not get why the world thinks SOAP over HTTP is so damn complicated. Hell I wrote a SOAP with attachments client the other day WITHOUT ANY TOOLS/ETC just for a customer who wanted to see it done that way (not generated) and it took only a few hours. (I used SAAJ. Sure its a java spec and impl library and it does a lot of the work for me, but so does an XML parser itself - I do not write my own parser every time I need to use XML either.)

Normally I use the tools, currently Axis and java2wsdl but looking more and more at Xfire every day. Take a plain ole Java bean, a service interface, a service description file that gives the namespace and serializer/deserializer definitions and cook it - viola a standalone SOAP service in a war file.

Next thing you know you have written an ant task and a Maven plugin to do the "cook" part for you automatically. You then just take an interface and an implementation in plain java and cook it up each time you need a service.

I also do attachments, based on recommendations from Mr. Cooper, using the "Content-ID" idiom where some element in the primary XML payload describes the attachment and then the server looks for that attachment using the "Content-ID" header of its part of the multipart/related message. This way it works with MIME/DIME/whatever. Regardless of how whatever specification encodes the "parts" they can send a header right, so done, I dont care how you handle the attachment so long as you tell me about it with a header.

I mean none of this is much harder than understanding HTTP in the first place and using XML over HTTP (yeah, you have to know the same type stuff to use REST).

Maybe I am oversimplifying things, maybe I am SOAP naive, and I admit that a lot of the original XML-RPC stuff was very unwieldy, but its really not currently all that hard to get SOAP over HTTP going and call it a web service, is it?

Sure REST is easier for some, but don't you have to have a conversation with the other side when you are using REST and state - "hey we are using this RESTy thing, it works like this"? Sometimes you do not have the luxury of that conversation, sometimes you have to say we use this specification, and since its a spec you are done. If you one or two companies calling your service, sure, use some RESTy stuff, but if you have many then it makes sense to agree on a non proprietary standard? (Or do I misunderstand REST? Is it standardized enough - whether formally or not because I admit that does not matter - to just point some one at a schema and say "go"? - and note I am not knocking REST - I obviously do not understand it well and have not used it - I get the idea but have never needed to look into it because I have used SOAP quite easily each time I needed a service - again though I am not knocking it, I am anti-knocking SOAP.)