A gentle intro to JSON and its concepts

Out of all the technologies that have emerged in the Web 2.0 world of Ajax powered apps, JSON is perhaps one of the most important. Its implications might not be apparent but JSON is a powerful technology that allows data interchange between traditional applications in an open and human readable format without the quirks of XML.

JSON (JavaScript Object Notation) is a lightweight computer data interchange format. It is a text-based, human-readable format for representing objects and other data structures and is mainly used to transmit such structured data over a network connection using serialization.

JSON finds its main application in Ajax web application programming, as a simple alternative to using XML for asynchronously transmitting structured information between client and server.

JSON is a subset of the object literal notation of JavaScript and is commonly used with that language. However the basic types and data structures of most other programming languages can also be represented in JSON, and the format can therefore be used to exchange structured data between programs written in different languages.

Code for parsing and generating JSON (the latter is also known as "stringifying") is available for a whole bunch of languages including (but not limited to) C, C++, C#, Java, JavaScript, Objective-C, The 3 P's - Perl | Python | PHP, Ruby, ColdFusion, Common Lisp, E, Erlang, Limbo, Lua, ML,Ruby, Smalltalk, Tcl and ActionScript.

JSON is built on two structures:

• A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.
• An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.

These are universal data structures. Virtually all modern programming languages support them in one form or another. It makes sense that a data format that is interchangeable with programming languages also be based on these structures.

Before we head into how JSON is useful in the Web 2.0 scenario, we have to elaborate a little bit on how Ajax works and where JSON fits in.

Ajax is a web development technology that makes the server responses faster by enabling the client-side scripts to retrieve only the required data from the server without retrieving a complete web page on each request, which will minimize the data transferred from the server. These requests usually retrieve xml formatted response, the xml responses are then parsed in the JavaScript code to render the results (which complicate the JavaScript code)

Need for JSON

Ajax allows Web-enabled applications to perform out-of-band client-server calls, establishing a separate channel on which to send and receive information from remote Web services. In layman's terms, updates and navigation sequences in Ajax applications are done outside the classical client-server context, which entails a complete screen refresh, with the information being received in the background (a.k.a out-of-band).

These application updates that are typically obtained from RESTful Web services, once received in a user's browser, need to be incorporated in the overall HTML page layout, which is exactly where XML proves to be more than a handful. Though the capabilities of most mainstream browsers have increased over the years with the support of scripting languages and plug-in support, many programming tasks still remain difficult or unnatural to perform, one of them being manipulating and processing text, which is typically done using DOM.

The complexity in using DOM lies in its function-based roots, with a simple modification or access to a data tree requiring numerous method calls. In addition, DOM is known for differing implementation details among various browsers; this process takes us to a very elaborate programming scheme with ample possibilities for a breakdown in cross-browser compatibility. So the outstanding question now becomes: How can a markup language be easily integrated into an HTML layout page to accommodate Ajax requirements?

The answer comes in the form of leveraging a common component in all mainstream browsers: The JavaScript engine. Instead of delivering Ajax updates in a format such as XML, which would require the use of a mechanism like DOM to access and incorporate data into a layout, a more natural and intuitive approach would be using a format that fits natively to the aforementioned engine, namely JSON.

Now that we have addressed the place JSON has with respect to XML and Ajax applications, let's take a closer look at the technical details behind JSON.

The first thing you should realize about JSON is that it remains a simple text format—just like XML—which is relatively easy to read and inspect with the naked eye. At a syntax level, what starts to set JSON apart from other formats is the characters used to separate data, which are mainly constrained to apostrophes ', brackets ( ), [ ], { }, colons :, and commas.

This listing illustrates what a JSON payload looks like:

{"addressbook": {"name": "Mary Lebow",
"address": {
"street": "5 Main Street"
"city": "San Diego, CA",
"zip": 91912,
},
"phoneNumbers": [
"619 332-3452",
"664 223-4667"
]
}
}

Human readable? Yes. Machine can parse easily? Yes. Similar to XML? Largely.

How does JSON manage to work?

The answer is that JSON works because most people don’t really need all that overhead, and because it’s often possible to do really interesting things with really simple formats. The World Wide Web has been churning along for over a decade with a markup language that originally had no standardized specification; these days it has specs, but they’re almost never enforced and are, in fact, usually thrown down to the ground and trampled upon. And it still works.

So HTML is a fast and loose format and it doesn’t have any concept of data types that the average programmer would recognize (though it does, in its own special way, have data types), and what rules it has with regards to what you can stick where are routinely ignored. And yet it works. It works really, really well. It works because most people who are using it don’t really need to do complex things with it. Most people who need markup languages for use on the web just want to do simple things like display some text and pictures. You don’t need a 500-page language specification to do that.

JSON is stricter than HTML in some ways; it expects you to obey the rules, but in exchange it gives you fewer rules to follow. And JSON works really, really well. It works because most people who are using it don’t really need to do complex things with it; most people who need data formats for use on the web just want to do simple things like fetch some data from over there and drop it into this web page here. You don’t need the massive overhead of XML-the-protocol-stack to do that.

There are people who genuinely have more complex needs, and I’m not going to try to say whether one thing or another will suit what they’re doing. But for the majority of us who are lounging around in the big belly of the web, JSON is just fine.

Benefits

Making use of JSON's data separators may not be too obvious at first glance, but there is a fundamental reason behind them: easier data access. As it turns out, the internal representation used by JavaScript engines for data structures like strings, arrays, and objects are precisely these same characters.

Where this leads us is to a more straightforward approach for accessing data than the alternate DOM technique, but let's take a look at a few JavaScript code snippets to illustrate this process. These snippets access the information in the previous JSON snippet:

• Name access from JSON: addressbook.name
• Street address access from JSON: addressbook.address.street
• First phone number access from JSON: addressbook.address.phoneNumbers[0]

If you have done some type of DOM programming, you will probably notice the contrast immediately, but just in case you haven't, here is an external resource to the Document Object Model, which contains a small example for navigating across data.

An added benefit of JSON is its less verbose nature. In XML, the opening and closing of tags is a necessity just for markup compliance, but in JSON's case all that's required is a simple bracket for closure. In data exchanges comprising a hundred or more fields, this additional XML markup can add to transit times.

Additionally, JSON has garnered the attention of many developers specializing in different programming languages, giving way to libraries capable of producing this format from environments as diverse as Haskell and Lisp to more mainstream options like C# and PHP.

Constraints

Like many benefits, JSON's less verbose format can cut both ways, and in this sense lacks a few of XML's properties. Namespaces, which allow the mixing of identical pieces of information in different contexts, is clearly missing in JSON. Another differing feature is that of attributes, since every JSON assignment is done with colons (:); when transforming XML to JSON it can be difficult to distinguish between what would be considered text between tags—XML CDATA—and the actual value of attributes.

You may also find the actual creation and validation of JSON a little more complex than an average XML fragment. In this sense, it may be that XML has had a head start in terms of developing tools for its processing. Nevertheless, and to ease any worries you may have in this area, we will be exploring some of the most mature JSON developments in our next section.

Is JSON for You?

Like all design choices in software, your requirements will provide the answer to this question. If your Web services consumers will be created in a classical, full-fledged programming environment like Java, .NET, PHP or Ruby, then you can probably make due without JSON. Given the open-ended capabilities of most programming language environments, providing you total configuration control not to mention access to custom libraries, parsers, or helper classes, the difference between consuming JSON, XML, or any other type of Web services payload should be negligible.

If on the other hand, your Web services consumers will be confined to the environment of a browser, JSON deserves serious consideration. Consuming Web services in a browser is not done for the sheer fun of it but rather as a real business requirement. If your manager comes to you and requires one of those "slick Web 2.0 interfaces" that appear to load data without a delay/refresh, then you would be entering the technical realm of Ajax and Web services consumption in browsers.

In these last circumstances, you would not only be limited to the processing environment of a machine located across a network, but one under tight control of a random user, limiting even the most resourceful developer to work with a lowest common denominator for processing text in browsers: the DOM, which as outlined earlier, is a difficult undertaking when compared to accessing a JSON tree.

When you get started with JSON the comparisons with XML are inevitable. Hard core XML fans tend to remark that JSON is redundant and everything it achieves is already implemented in XML. JSON is a better data exchange format. XML is a better document exchange format. Use the right tool for the right job.

Though the x in Ajax stands for XML, and Web services have come to the forefront by the steady use of this same format, it doesn't necessarily mean such an approach is cast in stone. As we have seen, XML has a few drawbacks when applied to Ajax-enabled applications, due to the text-processing capabilities in browsers. In this sense, JSON has emerged to provide a compelling alternative in this same context.

References ::

The first two references contain more material on JSON. The rest of them are comparisons of JSON with XML and suitability of JSON for RPC.

http://www.json.com/
http://www.json.org/xml.html
http://blogs.msdn.com/mikechampion/archive/2006/12/21/the-json-vs-xml-debate-begins-in-earnest.aspx
http://www.tbray.org/ongoing/When/200x/2006/12/21/JSON
http://www.infoq.com/news/2006/12/json-vs-xml-debate
http://copia.ogbuji.net/blog/2006-12-23/Why_JSON_v