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 + ")");

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
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.

JSON strengths
Fully automated way of de-serializing/serializing JavaScript objects,
minimum to no coding
Developers have to write JavaScript code to serialize/de-serialize to/from
Very good support by all browsers While XML parsers are built-in into all modern browsers, cross-browser XML
parsing can be tricky, e.g., see this
Concise format thanks to name/value pair -based approach Verbose 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 libraries Not 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 enforce
XML Schema or DTD can be used to define grammars
No namespace support, hence poor extensibility Good namespace support, many different extensibility options in Schema
Limited development tools support Supported by wide array of development and other (e.g., transformation)
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 yet
Supported 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. Pingback: JSON | ramprasadm
  7. 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.