right, i can't think of anyone that prefers xml over json-- xml seems too bloated, dom and sax parsers require lots of code to walk trees compared to just a single json parse call and then you can just directly access things in an object. though i have had to write several json decoder/encoders for special objects.
for my internal rest apis, the only response format i provide is json, this is for mvp purposes. though i will add xml when i publicize these apis.
My understanding is that REST imposes a bunch of restrictions about how an API is suppose to work.
For example the idea that you can just communicate a single base URL and document formats, and other urls are deduced from that. Which add complexity, but make the system more able to evolve.
My thinking is that these constraints are inappropriate for an internal API, where you could embed knowledge of how to construct a number of URL's in clients.
Also some tools, like .NET, have good support for mapping XML schema's to classes, and I don't know of equivalents for JSON.
To cite Wikipedia¹, “The XML encoding may therefore be shorter than the equivalent JSON encoding.” Please provide a fragment of XML document that is significantly more verbose than its JSON counterpart.
> dom and sax parsers require lots of code to walk trees compared to just a single json parse call and then you can just directly access things in an object.
Using DOM/SAX (especially SAX) is like walking the JSON's AST. You're doing it wrong (this is too low-level).
The second problem with this argument, is that people using it are selling you something that isn't real. You can't just ‘directly access things in object.’ You need to deal with untrusted input that is just coincidentally mapped to your very basic data structures (dictionaries, lists and numbers and strings). You will have to write schema—it will most likely be something that is different to each ecosystem (Y.Dataschema.JSON for Javascript, Colander for Python, etc.), and then you will consume exactly what you would consume with any other format, be it XML or Thrift or PB, that is your DAL objects, your representation objects if you're doing REST.
If you are doing it any other way, if you're doing it the naïve way, you're living in a fantasy land—you're using not only something that wouldn't scale, but something that is unsafe and unnecessary, yes!, verbose.
A very simple case for a web-application (and this is for where I argue), is that by using JSON.load() you're loading everything to memory. That makes you vulnerable for a simple dumb attack like this:
So you need to use streaming parser with a schema, to drop request when there's first sign of trouble, or you need to limit your webapps to requests that are no more than thiiis big, which of course limits you as to what you can include in that JSON document (if you want to include 5MB file, you will need to be ready for 5MB of nested dictionaries and lists). Not that you can't do that with JSON, however it's not just JSON.loads() anymore, now is it?
You asked why someone would prefer XML over JSON. Well apart from XML having dealt with all of this issues long time ago and is widely supported, how about the fact that XML is great for the Open Web and JSON will slowly kill it?²
for my internal rest apis, the only response format i provide is json, this is for mvp purposes. though i will add xml when i publicize these apis.