JSON Continues its Winning Streak Over XML

Romin Irani
Dec. 03 2010, 12:00AM EST

API providers and developers are making their choice quite clear when it comes to choosing between XML and JSON. A nearly unanimous choice seems to be JSON. Several API providers, including Twitter, have either stopped supporting the XML format or are even introducing newer versions of their API with only JSON support. In our ProgrammableWeb API directory, JSON seems to be the winner.

A couple of items are of interest this week in the XML versus JSON debate. We had earlier reported that come early December, Twitter plans to stop support for XML in its Streaming API. So in case you are late into this news, the deadline is Dec 6th. If your app still expects XML, you need to move quickly on that.

James Clark has written an interesting post titled XML vs the Web. He states several reasons for JSON being adopted of late: a simple and short specification and a combination of JSON with a dynamic programming language is probably the key to its ease of integration, simplicity and adoption across the web community. The blog post is worth reading since it balances the good work that has been done by XML and various tools/frameworks that have been built upon it. The best path ahead, according to James, is to take the best of XML and make it work well with the what the Web community wants, such as HTML5, JavaScript and JSON.

What is your take on the JSON versus XML debate? Or does it not matter anymore since JSON is widely accepted and you would rather focus on your application rather than worry about the data format war and relative arguments depending on which side you are?

Romin Irani Romin loves learning about new technologies and teaching it to others. Follow me on Google+



In an age where we are trying to simplify things XML unfortunately naturally lends itself to being complicated. Namespaces, heavy nesting and countless references to other elements are exactly the opposite of the movement we are seeing with NoSQL - driven by the need to keep data simple (and that storage isn't expensive any more). For data to be easily consumed it should be as simple as possible with a preference being on simple name/value pairs.

Although you can have complicated nesting and references in JSON if you really like we tend to see simpler JSON formats. This could just be because the target destination for a JSON file/feed could be a web browser where, even with the super-performant modern browsers, we still want to keep processing to a minimum.

Superfeedr recently bowed to the pressure of delivering Atom notifications in real-time by converting the updates to a JSON format: http://blog.superfeedr.com/json-pubsubhubbub-notification/ This is yet another clear indication that JSON is the preferred data format.

Hello Kurt,

Thanks for your comments. I agree with you on the fact that XML is quite well suited for complex integrations especially within the enterprise or in cases where XML-based document standards already exist i.e. Rosettanet, ebXML and the likes.

JSON seems to be preferred choice especially when it comes to building Mashups that are Web based.



We prefer to work with XML, and we actually convert JSON data to XML for processing. Unless I'm missing something, there are simply more and better tools for parsing and working with XML than with JSON - XSLT, various DOMDocument implementations. DOMDocument is a standard implementation, as well, which means, in theory, that your logic should be easily portable between different programming languages and platforms.

I like the fact that JSON's lean, and I do like JSON for some simpler integrations and tasks, but XML is the right choice for complex, multi app integrations, imo.


JSON is for programmers, XML is for consultants.

On a more serious note, JSON is ideally suited for providing APIs, whereas XML is a better choice for heavily annotated structured data, where not just data but also semantics have to be packed in the same file/stream.

The reason why JSON seems to be winning is that nowadays, when everything is going to the web, and the web has become a platform over which applications and humans communicate intensively, data exchange is less frequent than function/service calls, therefore the need for describing semantics, and thus using XML, is less ig than the need to provide APIs, and using JSON.

If most of the web traffic generated by web apps would consist of transferring lots of files (like product catalogs, complete stock quote lists - everything that stays valid as time passes), exported at one end and imported at the other end, instead of transferring transient, non-persistent results of function calls (search results, latest version of your cart on Amazon, route information on Google maps etc.), which immediately get processed on the client side and are then lost/irrelevant, XML would win over JSON. But since the web, although initially conceived as a document exchange platform, evolves towards a universal collaboration platform, this doesn't happen.