XML versus JSON - What is Best for Your App?

Tagged:  

One of the biggest debates in Ajax development today is JSON versus XML. This is at the heart of the data end of Ajax since you usually receive JSON or XML from the server side (although these are not the only methods of receiving data). Below I will be listing pros and cons of both methods.

If you have been developing Ajax applications for any length of time you will more than likely be familiar with XML data. You also know that XML data is very powerful and that there are quite a few ways to deal with the data. One way to deal with XML data is to simply apply a XSLT style sheet to the data (I won't have time in this post to go over the inconsistent browser support of XSLT, but it is something to look into if you want to do this). This is useful if you just want to display the data. However, if you want to do something programmatically with the data (like in the instance of a web service) you will need to parse the data nodes that are returned to the XMLHTTPRequest object (this is done by going through the object tag by tag and getting the needed data). Of course there are quite a few good pre-written libraries that can make going through the XML data easier and I recommend using a good one (I won't go into depth as to what libraries I prefer here, but perhaps in a future post). One thing to note is that if you want to get XML data from another domain you will have to use a server side proxy as the browser will not allow this type of receiving data across domains.

JSON is designed to be a more programmatic way of dealing with data. JSON (JavaScript Object Notation) is designed to return data as JavaScript objects. In an Ajax application using JSON you would receive text through the XMHTTPRequest object (or by directly getting the data through the script tag which I will touch on later) and then pass that text through an eval statement or use DOM manipulation to pass it into a script tag (if you haven't already read my post on using JSON without using eval click here to read the post). The power of this is that you can use the data in JavaScript without any parsing of the text. The down side would be if you just wanted to display the data there is no easy way to do this with JSON. JSON is great for web services that are coming from different domains since if you load the data through a script tag then you can get the data without a domain constraint.

The type of data that you use for your application will depend on quite a few factors. If you are going to be using the data programmatically then in most cases JSON is the better data method to use. On the other hand if you just want to display the data returned I would recommend XML. Of course there may be other factors such as if you are using a web service, which could dictate the data method. If you are getting data from a different domain and JSON is available this may be the better choice. For Ruby on Rails developers, if you would prefer to use JSON and XML is all that is available the 2.0 release allows you to change XML into JSON. One of the biggest reasons that people use JSON is the size of the data. In most cases JSON uses a lot less data to send to your application (of course this may very depending on the data and how the XML is formed).

I would recommend that you take a good look at the application that you are building and decide based on the above which type of data you should deal with. There may be more factors than the above including corporate rules and developer experience, but the above should have given you a good idea as to when to use either data method.

If you would like to contact me regarding any of the above you can make me your friend on Social Ajaxonomy and send a message to me through the service (Click here to go to my profile on Social Ajaxonomy).

I definitely prefer to use JSON since it is smaller but also because there are libraries for most back-end languages to convert the JSON object directly into a native object that can be used by the back-end language and vice-versa. I'm not sure about, though there most likely are, libraries to do the same with XML, but I never gave it any research since I've used JSON for everything.

JSON syntax is also native in Python, which I prefer to use for my daemons/web services, but PHP also now comes with a library for JSON.

I've also used just plain text with two fields delimited by a double pipe. The first field will have a status response, such as OK or ERR, and the second with the return of the function or an error message.

You of course not only look at how you want the data returned, but how you're going to parse that data and what you're going to do with it. Sometimes the method that will return the smallest package won't be the best implementation for your application.

A perfect example is a method that calls for tabular data from a database. If you're returning lots of data, it might be best to have the database simply return XML through an RPC request, as you can with MS-SQL. In other places it might be best to load the data as a collection of objects that have more attributes than the database provides and send that as JSON.

Unless JSON becomes standard, I won't use JSON at all. Why would I use a framework which is not at all having standard at all?

JSON is based on a standard (Standard ECMA-262 3rd Edition) and is fast becoming a standard for web services from companies like Yahoo and Google. I don't think that you can simply dismiss it because you don't consider it a standard.

Balaji: JSON is a subset of ECMA Script, not simply based on, it IS a part of JS. If you run eval('json code') you'll get a JS object. It's native and it's in the spec, how much more 'standard' do you want?

I always prefer to use XML because I could use it for any presentation tier, no matter it is Web enabled or JMS enabled or web services related. If your vision is always web related, go for it. JSON may works great with JavaScript but not with any tiers.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <pre> <div> <blockquote> <object> <embed> <img> <param>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Copy the characters (respecting upper/lower case) from the image.