JSON vs. XML from a .NET developer’s perspective

Often I see that people have the possibility to choose between JSON and XML when it comes to implementing some sort of API or service. I tried to cover some of the distinctive aspects of both document formats, so that when it comes to choosing one of these, it is going to be a choice that suits the specific needs. Please note the fact that some of the opinions expressed in this article are my personal and I don’t expect them to be the same my readers’. I am in no way covering all the aspects and differences, but rather try to highlight the most interesting ones.

Basically, there is no major functional difference as such between these two data formats. XML originated from SGML (Standard Generalized Markup Language), while JSON is developed based on JavaScript. Although its acronym stands for JavaScript Object Notation and it is indeed often used with JavaScript, it is a language-independent standard, therefore it can be used anywhere. JSON has one single specification that is set as permanent one, while XML has several versions defined by the standard committee.

It is arguable that JSON is more readable than XML. It has been mentioned in several articles that JSON is easier to understand when it is read by human beings. This fully depends on personal preferences; however I can understand XML faster than JSON. Let’s take a look at an example of the same structure presented both in XML and JSON:

<units><unit><name value=”some name” /><price value=”$100” /><location value=”shop” /></unit></units>

Here is the JSON representation:

{units:{unit:{name:{value:'”somename”'},price:{value:'”100”'},location:{value:'”shop”'}}}}

If you have worked with scripting languages before, then you probably find the JSON syntax quite familiar. If not, from the first sight it could be difficult to understand the tree structure of the data obtained through it. Personally, I find XML a little bit more structured and clear.

The JSON parsing can be a bit more frustrating since there is no integrated JSON parser in .NET (some tools are available if you are working with Silverlight, though). There are third-party serializers, but not that many parsers. Of course, you can always write your own parser. But when it comes to tools to work with JSON, there will be some work to be done. The complete opposite of this is XML, that can be read through XmlDocument and manipulated via XPath.

XML can contain binary data, while JSON is only used to send plain text data (although, it can contain HTML tags, for example). JSON has no <![CDATA[ that will let the developer pass non-JSON structured data. While this can be an advantage for some situations, it can also cause some infrastructure problems when it comes to massive extensibility.

Validation is yet another topic that needs to be covered. XML has a strong validation potential, therefore the input and output can be easily verified for the correct structure. JSON is a different story, and since it doesn’t have a single well-defined schema, validation can be one interesting task. And although there are situations that don’t require validation (so basically this problem isn’t that big of an issue), in most cases validation is a must (for user-introduced data that is sent to a server, for example).

For those concerned about JSON mass adoption, it is not that much used as XML, however, it is already used by such services as Twitter for their REST API (although Twitter provides both JSON and XML data representation for most of the API methods, some of them are only available in JSON). Some other big companies (like Google) are also implementing JSON data mechanisms for their projects (GData comes to mind). JSON is gaining its share quite fast, and although it can be a bit unusual to use it when it comes to interoperability due to its limited user base compared to XML, it definitely has some interesting ways to be applied to.

Personally, I mostly use XML for data manipulation. I find it a bit more simplified compared to JSON (once again, this is a personal opinion) and the tree structure can be visually identified. However, I highly recommend developers to take a look at JSON and its organization, since soon enough we will see more services that will inject JSON data in their architecture.