JSON is a simple object serialization approach based on the JavaScript object initializers syntax. The code for initializer (object literal) is put into a string and then interpreted using JavaScript eval() function or JSON parser (which is very lightweight):

serializedObj='{firstName:"john", lastName:"doe"}';
...
// This is just an example, JSON parser should be used instead
// to avoid security vulnerabilities of "eval"
var obj = eval("(" + serializedObj + ")");
document.getElementById("firstName").innerHTML=person.firstName;

JSON is used extensively in various AJAX frameworks and toolkits to provide easy object serialization for remote calls. It is is supported by both GWT and DOJO. There is a growing realization that perhaps JSON should be considered as an option when implementing SOA, for example Dion Hinchcliffe recently published a blog entry suggesting that JSON (and other Web 2.0 technologies) must be seriously considered by SOA architects.

So what are the benefits of using JSON relative to XML (for this comparison I want to focus just on XML and stay away from SOAP)? Here is my brief take on that, there are also numerous other articles and posts on the subjects.

JSONXML
JSON strengths
Fully automated way of de-serializing/serializing JavaScript objects, minimum to no codingDevelopers have to write JavaScript code to serialize/de-serialize to/from XML
Very good support by all browsersWhile XML parsers are built-in into all modern browsers, cross-browser XML parsing can be tricky, e.g., see this article
Concise format thanks to name/value pair -based approachVerbose format because of tags and namespaces
Fast object de-serialization in JavaScript (based on anecdotal evidence )Slower de-serialization in JavaScript (based on anecdotal evidence )
Supported by many AJAX toolkits and JavaScript librariesNot very well supported by AJAX toolkits
Simple API (available for JavaScript and many other languages)More complex APIs
JSON weaknesses
No support for formal grammar definition, hence interface contracts are hard to communicate and enforceXML Schema or DTD can be used to define grammars
No namespace support, hence poor extensibilityGood namespace support, many different extensibility options in Schema
Limited development tools supportSupported by wide array of development and other (e.g., transformation) tools
Narrow focus, used for RPC only, primarily with JavaScript clients (although one can argue that it's one of the strengths)Broad focus - can be used for RPC, EDI, metadata, you name it
No support in Web services -related products (application servers, ESBs, etc), at least not yetSupported by all Web services products

So the bottom line is that JSON and XML are, of course, two very different technologies; XML is much broader in scope so I'm not even sure if comparing them side by side is fair.

As an object serialization technology for AJAX (or should it now be called AJAJ since we've replaced XML with JSON?) JSON looks very appealing. Anybody who ever tried parsing SOAP directly in a browser (while having to support multiple browsers) can attest that this is not a straightforward task. JSON simplifies this task dramatically. So I think that ESB vendors should definitely start thinking about adding JSON to the list of formats they support.

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.

13 thoughts on “JSON Pros and Cons

  1. I’ve been wondering about what acronym should be used for “Asynchronous JavaScript and JSON”. But if you write it all out you get “Asynchronous JavaScript and JavaScript Object Notation”, so “JavaScript” is redundant and the phrase can be shortened to “Asynchronous JavaScript Object Notation”. AJON?

    Thanks for the writeup!

  2. The comparison gave the impression that JSON can only be used with Javascript.
    According the author, he defined JSON using javascript but it is a standard that is not confined to Javascript. It is “…a” text format that is completely language independent.”

    Go to http://www.JSON.org and read about JSON. Also there are links that answers some of the issues raised in this article.

    I am not for or against JSON. XML and JSON both has their own merits. A good developer will pick the best to use for the situation.

  3. Raymond:
    JSON is indeed language independent, however, the balance shifts when you are not using JavaScript – most other languages have very good Web services and XML support, so I’m not sure what would be the use case for JSON, say, in .NET or Java environment. It’s the lack of good XML support in browsers that makes JSON so appealing IMO.

  4. Every technology has its own merits and de-merits. As per my experience, JSON is good for sending small information over http. when use along with REST, it offers lots of flexibility, specially when working in cross technology domain.

  5. its all about saving hardware and performance resources… time consuming and a lot of stupid questions.
    hardware is evolving every day its all concerns about performance could be obsolete soon.

  6. Respected sir

    I have to insert json object into oracle table using procedure .
    for this purpose plz let me know what process should i follow is there any need to include some package and from where i can get that

    if you have sample example for json object insertion in oracle .
    so plz send it to my mail(sahareanish@gmail.com) or as a reply in this forum.

    (this is my edited question my only and very clear motto is that i want to insert JSON object in Oracle table)

    Many Thanks in Advance

    Anish Sahare

Comments are closed.