I still haven't really used JSON in a real world project - I pretty much always rely on XML.
Any time you need to move a lot of data with a XHR call.
We have started moving all our XHR calls over to JSON since its at least 4x smaller than our old XML format.
Now with browsers, like Firefox 3.5, having native JSON support its a lot easier to use.
- It's easy
- It's simple to convert from strings to javascript objects by calling eval(), but be careful. Have a look at this question for more info on eval().
- You don't have to parse XML (could mean a performance increase in some situations).
But, you loose some of the great compatibility that XML offers.
I prefer JSON whenever I have a choice. It's more self-documenting than XML (assuming no schema) because it differentiates between:
- records (objects, named sub-items, order is not significant) and
- lists (arrays, numbered sub-items, order is significant).
In mere well-formed XML, these two things are often both represented by elements. Naively we might think to use XML sub-elements for list items, and XML attributes for named properties. But then named property values can only be strings, not arbitrary nested structures. And the element name of sub-elements in lists are often redundant.
XML is simply a poor fit for its most common application (representing object hierarchies), and JSON is a better fit.
This is unsurprising as XML is based on SGML which was originally intended for applying mark-up within a stream of plain text - a very different application.
For me, JSON is just easier to use, lower overhead, easier to manipulate and for me, my chosen tools of dojo + PHP a heck of a lot easier to take data from the server and integrate it into the UI.
In short JSON is a decent interop option, in particular for javascript. If it suffices, what's the point of XML?
For more complex data, json is less advantageous in my mind. XML may be less "efficient", but I've rarely had any issue with that - but the forced naming of elements in xml means that it's often a lot easy to debug - this is in particular true for projects that span several organisations - B2B interop, say. XML has better tooling in the form of XSLT, XSD, integration into many languages (VB.NET's native XML, say, and LINQ to XML), and it's more naturally "open" - it's easier to extend XML with a new element without disrupting the old schema, whereas a list in json contains unnamed items, making functional collisions more likely. Of course, you can work around all these things in JSON, but that requires foresight and planning effort. Finally, though most languages have decent XML support, javascript in particular does not, making building XML something a pain unless you use a few helper functions (The DOM does not win any design prizes here).
In short; I use XML for all data-interchange and likely to be longer-term complex API's, and json specifically for lightweight client server stuff where a strict API isn't needed and thus xml's imperfect match to OO and slightly heavier weight transmission are a drag that's not matched by any of it's benefits. If you're going to do a quick bit of AJAX updating, JSON works fine and lets you avoid the OO/XML impedance mismatch (and the smaller serialization is icing on the cake).
I've never worked on a large-enough application where the bandwidth savings of JSON made an impact, but if you're google or microsoft, I'm sure that's a significant benefit too (and you'll probably need to spend oodles on planning and foresight anyhow, since any API you release will quickly become a dependancy anyhow.)
Always. For all of the projects I am currently involved in I use JSON.
http://www.techyouruniverse.com/software/json-vs-xml-vs-serialize-for-data is a pretty solid resource on why (not my site).
It's a great, easy, fast way to integrate php with javascript. It also makes a fantastic way to store preferences for site users in a database.
JSON is a much simpler data format. Even in well-specified XML like XML with Schema, as used in many SOAP web services, interoperability of data types is difficult. Even plain integers and booleans can cause interop problems, and more complex structures like nested arrays with optional values are very difficult to make work across different type systems. JSON is a very simple clearly specified type system of its own and seems to be easier for interop.
Another significant drawback of XML is the parsing complexity leads to security problems. Simple XML is simple. But most XML libraries parse complete XML, including PIs and DTDs and entity expansions. It's easy to use those XML libraries incorrectly, leading to XXE vulnerabilities and the like. JSON can also be used insecurely if you simply eval() the JSON data as code. But there are plenty of easy to use JSON parsing libraries that treat JSON data securely as data, not code.
- Much smaller overhead
- Easier to read
- Auto-formated in Firebug with header "application/json"