JSON Web Services – the XML JSON debate further ahead

I have been keeping a track of JSON (JavaScript Object Notation) versus XML for the past couple of months when AJAX came up as a big bang approach. Arun Gupta also recounts his similar experience with the XML JSON debate and concludes,

XML is document-oriented and JSON is data-oriented. So if you want to deal with highly structured documents that requires a complex structure, binary data, exact ordering of elements and be able to render itself then use XML. If you are focused on light-weight data exchange then JSON is the way to go.

In my opinion too JSON is handy only for light weight data transfer and nothing more than that. But with more nesting of data JSON can get utterly complex than XML. With XML you can define Schemas, form standardized document structures , extend exisiting document structures or import them when needed. The namespaces concept of XML has been very well established and incorporated in today’s applications and libraries.

XML Dominance
XML got more acceptance due to the already well established markup languages like HTML. Due to standardization by W3C it got quickly incorporated into the big vendors tools. Even a well documented JSP is purely XML. The main advantage of XML success is the XML Schema defintion language (XSD) which has given rise to numerous other standards like SOAP, WSDL etc. It is a very flexible and extensible language.

If you look behind the scenes a bit, XML has been reigning from the past and its usage in the industry has become massive. You might not be aware but all the big applications use XML either for storage, transfer, presentation or configuration of data and also meta data. MS SQL uses XML to transfer data from one database to other. MS WORD uses XML to provide formatting of user input content in the documents.

JSON- Some Facts
Coming back to JSON, the main fact which goes against JSON is it is not standardized. But now if JSON wants to establish its presence then the only field in my opinion would be SOA web services and AJAX where, it has received a lot of attention. Lately the debate on using web services with JSON has started. XML being heavy puts somewhat a hindrance on the acceptance of web services since the network infrastructure needs to get upgraded to get quicker adoption of XML RPC web services. With JSON, if web services give a higher throughput then it might be time to cash upon its acceptance for data transfer. Alexander writes about JSON pros and cons in his blog MyArch,

One of the keys to SOA success is that it should be easy to consume a service, i.e., the entry barrier for service consumers must be low to support “grass root” SOA adoption. While a top-down SOA effort may succeed, it will certainly take longer than bottom-up (“grass-root”) approach when developers are able to consume services as they see fit. AJAX/JSON fits this bill perfectly – it is easily understood by developers and it does not require any Web services -specific tools or infrastructure.So overall I’m pretty enthusiastic about JSON.

Advantages of JSON
The advantage of using JSON instead of XML is in the inheritent quality of data structuring in JSON. JSON is more closer to being a HashMap as in java or an associative array in some other languages like PHP. Hence it does not require parsing libraries in an application as XML does. The time spent however, on parsing XML into the native language, is not so much significant considering the fast processing power of machines today.

The comparison of XML and JSON lies more on the network bandwidth aspect. JSON can take almost half of the bandwidth as XML for transferring the same data. It can achieve the same throughput as passing simple objects in the network in a distributed computing environment.

JSON Web Services?
It would be interesting to see how would a SOAP message with JSON look like. You have to remember that WSDL is an extensible language and till date only HTTP Bindings and SOAP Bindings have been defined for it. It wont be long before we see JSON Bindings coming into the WSDL documents. Who would not want a quick data transfer while using web services into the application?

AJAX with JSON has got accepted well since JavaScript has the inbuilt capability to handle JSON data and if JSON web services start getting acceptance it might get well flourished to reach the popularity charts as XML did. Is the web service industry looking for a paradigm shift or are we just building a castle in the air?

8 thoughts on “JSON Web Services – the XML JSON debate further ahead

  1. Err… JSON is a subset of Javascript objects (boolean, number, string, array, null, undefined, and object [but only with attributes of the above types]) which is serialized into a string and can be directly evaluate by Javascript.

    Thus, “Hence it does not require parsing libraries in an application as XML does,” is not exactly true. In Javascript that’s the case since you can either use eval() directly, but in other languages you need a library to deserialize the JSON input. For example if you try to eval(‘true’) in python you’ll get:
    >>> eval(‘true’)
    Traceback (most recent call last):
    File “”, line 1, in ?
    File “”, line 0, in ?
    NameError: name ‘true’ is not defined

    The key reason to use JSON is that, being an object notation, it was designed for interchanging data types, whereas XML was designed as a structured format for data and has ‘recently’ became a system for doing data-type interchange. These issues are discussed on the JSON website: http://www.json.org/xml.html

  2. Hi Alexander,
    I have read about the XML JSON debate in the link you provided.
    I havent tried JSON myself though.

    What you say is correct but in my opinion if JSON is an alternative to XML then probably we can use it in web services in future for all its good purposes.

  3. I already use JSON for all of my web application APIs. They accept data encoded with JSON and return a result encoded with JSON. They’re not method call oriented but rather RESTful, but I’ve seen some convincing RPC implementations using JSON as well.

  4. I have seen this many time people referring to RESTful services, as you did. I believe that HTTP is a REST based protocol and web services have been implemented on HTTP only. But why is it so that people sometimes refer to the web services as RESTFUL services. Isn’t REST inheritantly applicable to the term “web services”. Or is there something like non RESTful services?

  5. Well, a RESTful web service has a number of meanings to a number of people and a number of things. It is true that HTTP is RESTful in that it is designed to allow for transitions in state. Something like XML-RPC doesn’t really take advantage of this part of HTTP’s design. RESTful apis usually look something like

    GET /user – list of users
    PUT /user – Add a user
    GET /user/1 – info about userid 1
    DELETE /user/1 – Delete userid 1
    POST /user/1 – Update info for userid 1

    Instead of providing method calls for this. There are some great pages explaining why this is better then a SOA style web service or an XML-RPC one. I particularly like this one:
    http://duncan-cragg.org/blog/post/getting-data-rest-dialogues/

  6. If you want human readbility, xml makes sense. Try reading a json file and finding what data ends where can be confusing….

    Like you mentioned the use of xml in config files for ant; think if they were in json, we would never find what ended where.

    Anything that can be written in xml can be written in json. Your choice should be decided by who is going to read your file.

    If your code is going to be read only by a parser(the java-script eval or any other) json does a nice job. It is easier to parse. It is much more smaller in size. Can save a lot of unwanted data going around. I have noticed that sometimes the metadata doing around in xml is more than the read data transfered… a huge overhead. Definitely not needed if your code will never be seen by a human.

  7. Hi pascal,

    JSON is data centric and XML is meta data centric.
    JSON and XML are never intended to be read by humans. I understand your concern where you mention the fact if JSON was used in Ant. But tell me, do you ever transfer Ant Build Files to any requesting service?

    I want to highlight the case of transfer of data and NOT on configuring meta data. Of course XML is far better but only while configuring meta data. If you use XML for heavy duty data transmission your bandwidth gets chocked up. Such situations can be handled by some slternative mechanisms like JSON. And here I presume you do the data transfer with API’s and not hand code the JSON fragment before transfer.

    Finally it all boils to the case of data transmission and is never the case of readability when choosing a communication medium. Ever read an RMI object?

  8. I use PHP and i think JSON is wonderful.
    i use both googles youtube & dictionary JSON web services, their service is incredibly fast (due to the small page size) decoding JSON in PHP is almost instantaneous too.
    JSON can be decoded either into stdClass Object or an Array.

    stdClass Object:
    $varName = json_decode($jsonData);

    Array:
    $varName = json_decode($jsonData, true);

    wonderful stuff!! <3

    althought not all JSON data is formed well, and needs string replacements with some services before decoding..

    anyhow..

    It's wonderful stuff!! <3

Leave a Reply

Your email address will not be published. Required fields are marked *