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.
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"); alert(elements.firstChild.textContent);
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); alert(customer.name);
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.