There exists a peculiar amnesia in software engineering regarding XML. Mention it in most circles and you will receive knowing smiles, dismissive waves, the sort of patronizing acknowledgment reserved for technologies deemed passé. “Oh, XML,” they say, as if the very syllables carry the weight of obsolescence. “We use JSON now. Much cleaner.”
This is actually why my colleagues and I helped kill off XML.
XML APIs require extensive expertise to upgrade asynchronously (and this expertise is vanishingly rare). More typically all XML endpoints must be upgraded during the same unscheduled downtime.
JSON allows unexpected fields to be added and ignored until each participant can be upgraded, separately and asynchronously. It makes a massive difference in the resilience of the overall system.
I really really liked XML when I first adopted it, because before that I was flinging binary data across the web, which was utterly awful.
But XML for the web is exactly where it belongs - buried and forgotten.
Also, it is worth noting that JSON can be validated to satisfy that engineering impulse. The serialize/deserialize step will catch basic flaws, and then the validator simply has to be designed to know which JSON fields it should actually care about. This gets much more resilient results than XMLs brittle all-in-one shema specification system - which immediately becomes stale, and isn’t actually correct for every endpoint, anyway.
The shared single schema typically described every requirement of every endpoint, not any single endpoint’s actual needs. This resulted in needless brittleness, and is one reason we had such a strong push for “microservices”. Microservices could each justify their own schema, and so be a bit less brittle.
That said, I would love a good standard declarative configuration JSON validator, as long as it supported custom configs at each endpoint.
I’m not sure I follow the all-in-one schema issue? Won’t each endpoint have its own schema for its response? And if you’re updating things asynchronously then doesn’t versioning each endpoint effectively solve all the problems? That way you have all the resilience of the xml validation along with the flexibility of supplying older objects until each participant is updated.
They should, but often didn’t. Today’s IT folks consider microservices the reasonable default. But the logic back when XML was popular tended to be “XML APIs are very expensive to maintain. Let us save time and only maintain one.”
XML schema validation meant that if anything changed on any endpoint covered by the schema, all messages would start failing. This was completely preventable, but only by an expert in the XML specification - and there were very few such experts. It was much more common to shut everything down, upgrade everything, and hope it all came back online.
But yes, splitting the endpoint into separate schema files solved many of the issues. It just did so too late to make much difference in the hatred for it.
And really, the remaining issues with the XML stack - dependency hell due to sprawling useless feature set, poor documentation, and huge security holes due to sprawling useless feature set - were still enough to put the last nail in it’s coffin.