How and why REST will beat SOAP

In the past weeks and months, the REST versus SOAP debate has flamed yet once again - however, the balance this time definitely is in favour of REST.
So it seems like REST will be the new SOAP - meaning that today's Enterprises that have any form of Service Oriented Architecture will replace their current implementations by those fit for the future

That would mean, to a good extent, replacing XML by JSON, and SOAP RPC by HTTP's CRUD: PUT, GET, POST and DELETE

SOAP was originally introduced to and by Microsoft, and was one in a range of futuristic machine-to-machine self-describing protocols. Needless to say, the world wasn't ready then, nor is it now. Current implementations of SOAP are arbitrary, proprietary, bi-lateral human agreements at best. In their worst form, SOAP implementations are dictated by governments and other bodies of power and bring nothing else to the other party but a cumbersome and hard-coupled interface

SOAP was adopted by the W3C working Group which, as you can see, was closed on July 10th 2009. SOAP Part 1 describes in length the SOAP envelope, the fanciest feature of it all. Its contents?

The SOAP Envelope element information item has:

• A [local name] of Envelope.
• A [namespace name] of "http://www.w3.org/2003/05/soap-envelope".
• Zero or more namespace-qualified attribute information items amongst its [attributes] property.
• One or two element information items in its [children] property in order as follows:
• An optional Header element information item (see 5.2 SOAP Header).
• A mandatory Body element information item (see 5.3 SOAP Body).

Wow! That's an ego-trip for sure. So I MUST call it Envelope, and pledge my allegiance to the W3C gods by referencing one of their URLs, and other than that I'm free to go? That can't be right!

Well, it is. And was. For years. I've fiercely objected to SOAP since a decade ago, saying it brought nothing else but confusing rubbish, while adding no value at all to either sender or receiver of it. I said the same of XML, and must admit that I'm pleased that XML is no longer officially supported by Twitter, nor Facebook - nor has it ever been in use by Google. Taking these 3 largest content distributors of the consumer world, I think that means something. SOAP? Neither of them supported that at any time - of course

Anyway, the future is now, and here: JSON and REST. No more bloated XML that takes up Gigabytes of memory just to parse a 1 MB XML message, no more "500 kilobytes of tags, 4 kilobytes of content" complaints (yes that is implementation, but some if not most of that comes along with adoption), no more.
JSON is here, a slim, lean and mean way to construct a message, and even better, it gets automatically parsed by Java

The SOAP envelope? Oh my. Have you been there, done that? In endless debates about return values and especially messages, each of them more weary than the other? Discussions about capitals versus lower case letters? That certainly was of great benefit to the business, wasn't it?
The SOAP Envelope will simply get replaced by the HTTP header. Standardised, uniform, non-debatable. It's a standard that was present even before SOAP was invented, so I guess it just takes a long time before people see what there is in front of their eyes - or something like that

In tomorrow's post I'll share more thoughts on SOAP vs REST. Meanwhile, REST assured (hehe) that each and every XML/SOAP implementation in this world is due for a makeover