I chuckled my way through this post on ‘Why SOAP lost’ because it seems to be missing some fundamental observations.
SOAP (like Java) was designed for structured use in well designed systems. most developers shy away from anything structured. It gets in the way of just writing code (or more frequently, downloading code and pasting into the editor). Much better to use JSON and write a bunch of validation code than to use SOAP/XML and re-use existing robust, well tested parsers and validators. I know, I am making a big assumption there – that a developer would actually write validation code. The more ad hoc the development process, the more ‘agile’ it is and that is good, right? Ask your friendly neighborhood QA and operations people about the value of optimizing for slap-dash development versus designing for sustainability, consistency, uptime and performance.
XML is ‘much harder to read’ than JSON? Right. Give someone a JSON document with 2-3 levels of nesting and an array or two and see how much easier they think JSON is. XML can be verbose, but that is for the purpose of clarity. Oh, and kudos for adding the line breaks in front of the namespace declarations to make your example XML look more ‘verbose’.
I’m not sure I understand the comment about SOAP usage of HTTP POST being a hardship because it can’t be tested in a browser. Easily solved by using something like the POSTman plugin in your browser. And I suppose the author is one of the service designers who doesn’t use anything but HTTP GET and returns everything (including errors) with an HTTP status of 200. Because, you know, that is easier – especially when your production environment is a browser and not a server or something exotic like that.
The last set of bullet items in the post is missing a little something as well:
Laziness, when it is the primary decision criteria, optimizes for development and sacrifices everything else. That is like optimizing for 5% or less of the lifecycle of that code. Just dumb. Be a nice person and drink your steaming cup of STFU when your YAGNI snark causes 20 hours of production downtime a month because the code has no design rigor behind it and certainly doesn’t take supportability concerns into consideration.