Posted by: dotnetninja | April 13, 2008


My headline was at first Rest with WCF and JSON there I wanted to show how “easy” this can be implemented and used later in “real life” with WCF. But when started to write I thought much about JSON and XML and decided to split article in two, three parts.

I am a big fan of Restful design. The whole World Wide Web is built on the same principle. Simply explained, with REST, every piece of information has its own URL. But more about REST in the next article.

Remembering the old days when we used SOAP to send messages over the wire, with .Net 1.0/1.1 Web Services. Because of the poor performance due to the large messages transferring, with schemas of DataSets (bad design) and bad connection we had to zip messages with GZip and unzip it before showing the end user.

Since then I have seen many application/services sending large xml messages (SOAP) and there was still same design faults (including schemas definition in each response/request).

There was a misperception that with just using XML every problem will be solved. People, read designers, architects and developers thought that xml message format was the “Holy Grail”, and it was really abused.

When technique freaks rediscovered AJAX (Asynchronous Java Script and Xml), yes rediscovered, since we could use it since release of the Internet Explorer 5 back in 1998, they thought, o we can use Web Services with SOAP and bunch of xml messages, and call it directly from the browser using XmlHttpRequest very simply and again all our problems are solved, o great Web 2.0 is here.

Again messages send with soap where too large, in some cases, system was bad designed (again) and it took too long time to retrieve them and now and then you would get timeout with response, the SOP or Same Origin Problem also arise because of the use of the XMLHttpRequest object, which involve the browser restriction that prohibits pulling data from another domain.

The limitation of the client (read browser) was also parsing messages and retrieving information from message, which also took time. Here in one great article by Jens Riboe about performance Web Service Performance (written for 5-6 years). There are some interesting thoughts with measured performance and the result shows that when sending messages in different formats one significant bottleneck can be parsing mechanism when exchanging data.

Now the JSON popularity is together with the AJAX phenomenon, most AJAX implementations focus soley on XML as the delivery mechanism for data.

My thought was that XML is good for an envelope, but not necessarily the best choice for transmitting large amounts of data, as it is too verbose. JSON offers a lightweight format, is easily serialisable/deserialisable and maps nicely to native datatypes. Microsft Ajax is using also JSON to exchange data.

To investigate performance of Json and Xml, I made simple test comparing them. My first thoughts were that JSON may be something like x faster to parse than XML in today’s browsers, JSON parsing ends up with something akin to a  typed “business object” rather than an untyped DOM tree, I also thought that serialized Javascript objects will fit better client side scripting (which is primary done in Javascript).

With XML you can use the responseXML property of the XMLHTTPRequest object to get an XML object:

var xml = xhttp.responseXML;   
var elements = xml.getElementsByTagName("name");   


Apparently, to process the response data, you need to walk the DOM tree. This is a very tedious exercise, and is error prone. Unfortunately, DOM is what we are left with on the browser side.

Alternatively the JSON string can be accessed using the responseText property of the XMLHTTPRequest object.

var customer = eval(xhttp.responseText);   

With a simple eval(), you could evaluate the response to a JavaScript object. Once this step is done, to access the data, you just access the properties of the evaluated object. This is the most elegant part of JSON.

The test showed that there was no significant difference. Still I was using Internet Explorer 7 and maybe because I was using MSXML object and JSON is using Javascript there was some overhead there. Again this was an really simple test but again I did not expect this result.



XML is built for giving semantic meaning two text within documents. JSON is built for data structures. Unfortunately, most developers have not understood this, and just used whatever that felt was the most popular. Yes, XML can describe data structures, but when you start really looking at the syntax for describing simple things like empty arrays in XML, it should be obvious to people, that JSON is much more naturally built for data structures. var person = eval(xhr.responseText);

JSON is important because it is better supported in the browser than XML. alert(person.firstName); var xml = xhr.responseXML; var elements = xml.getElementsByTagName(“firstName”);

With JSON there are still some potential security features built into modern browsers that prevent web pages from initiating certain classes of communication with web servers on domains other than the one hosting the page. This “problem” is accurately described in the article Fixing AJAX: XMLHttpRequest Considered Harmful. But also badly escaped XML can also lead to cross-site scripting attacks.

Again it is upp to you to fix security either using xml or json or other.

At the end I will recommend use of the binary format where possible.

Use JSON when representing data structures or when having data oriented applications.

Use xml when sending message like a document than a structure, or if the order of the data matters, or if the data is potentially long-lived

Also check out SXML which is SXML is particularly suitable for Scheme-based XML/HTML authoring, which is a complete representation of arbitrary DTDless XML in standard S-expressions.


  1. Nice article. Interesting on differences between XML and JSON. Hope it will come more of this kind in-depth analysis.

  2. […] But when started to write I thought much about json and XML and decided to split article in two, th Creating a SQL to JSON Server in ASP.NETThis article demonstrates a way to convert the result […]

Leave a Reply to Sven Arskerlund Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: