Blogging Task 7 – Json

Web services are practically synonymous with XML, the payload format used for communicating between client and server. However, the application architecture imposed by the appearance of Ajax and REST techniques has forced many to contemplate alternatives like JavaScript Object Notation (JSON).

JSON has come to the attention of Web service providers as a lighter and more friendly format for Web services clients in the form of a browser, or what would essentially be an Ajax-enabled application accessing RESTful Web services.

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

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. There is no formal study concluding that JSON is more efficient than XML over the wire; it’s simply a matter of byte-to-byte comparison, where an equivalent JSON and XML payload is always smaller in the former than in the latter format. How much of a difference this makes, especially in the light of the new XML compression formats, remains to be seen.

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 ( see the References section for details ).

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.

References: http://dev2dev.bea.com/