3 ms·
Back in the 2010s these things were all the rage in systems where you used XML in combination with technologies like WS-Security (i.e. signed SOAP requests). I
by davewritescode 4y ago
Back in the 2010s these things were all the rage in systems where you used XML in combination with technologies like WS-Security (i.e. signed SOAP requests). I suspect these things are still all over the DoD. I remember all sorts of fun issues with different vendor stacks not interoperating a together well so it was useful to have a standard layer to validate messages before they got to the backend.
The reason all these XML based protocols failed is that
1. XML is extremely space inefficient to begin with so all messages are bloated
2. The promise of interoperability between systems never really materialized. Finding a common set of configurations that would work across the multiple Java stacks, .NET and whatever else was out there at the time was a nearly impossible task.
It turns out simple JSON and API specs were more than enough.
- bzzzt 4y agoThere's still a lot of SAML and SOAP being spoken on the Internet, so I wouldn't call it a failed protocol. Interoperability between Java and .NET was a solved problem somewhere around 2008. Most important reason XML was replaced by JSON for the majority of use cases was the parser had a lot of complexity and wasn't implemented as well for other languages that were considered 'less serious' at the time. If you built with Rails or PHP you probably had to deal with badly implemented XML and SOAP libraries.
- boole1854 4y ago> Most important reason XML was replaced by JSON for the majority of use cases was the parser had a lot of complexity and wasn't implemented as well for other languages... I think it had more to do with: 1) An advantage of XML was supposed to be that it was human-readable, which meant it would be easier for developers to work with and debug. The problem was that many XML documents were so bloated with tags within tags within tags and redundant attributes all over the place, that in practice it was extremely painful for a human to read. JSON is better, in practice. 2) For better or for worse, JavaScript became ubiquitous, and there is a simple, clean isomorphism between JSON to in-memory JavaScript objects (obviously, since that's what the JSON name means).