In this tip posted on SearchWebServices.com, Daniel Rubio digs into the advantages of JavaScript Object Notation (JSON), and how JSON as an approach has recently gained popularity with Ajax services and Web-based clients. JSON is a data format, but one which is more naturally fit for browser data consumption. JSON is a subset to JavaScript, and by structuring a data payload as a JSON response, you are effectively bypassing the need to parse an XML document in a browser to get to the actual data. JSON uses a stripped-down syntax compliant with the native JavaScript interpreter provided on all browsers. Access and navigation to JSON data is done through the same standard JavaScript notation used to access string, array or hashtable values in a typical JavaScript application.

At first sight JSON and XML are similar, but it's only when you get down to accessing the internal data structures that you realize JSON is easier to deal with in a browser setting. Tapping values in JSON is as simple as navigating a JavaScript object due to its syntax, but doing so for an XML response entails a lengthier process, one of parsing and navigating an ad-hoc tree structure not particularly natural to a browser environment. Truth be told, JSON dates back to 2002, so it's nothing out of the ordinary to structure data in a native JavaScript structure like an array or hashtable for later consumption by a browser. So why is it that JSON has recently gained popularity? The reason is another technology which has grown in recent times -- Ajax.

Rubio goes on to explain how JSON is an ideal solution to the increased demand that Ajax brings for processing data without asynchronous communication.

By using an alternate syntax which is natively related to a browser's JavaScript engine, JSON is an ideal combination for services bound to clients in the form of a browser.

What benefits have you been experiencing while using JSON? Do you agree that its recent boost in popularity has been due to Ajax?

We've been using JSON as our AJAX payload since long before either term was coined, and yes, for in-browser manipulation it's definitely easier to work with for any data-related purpose. Some people use an XML payload because they use XSLT to go to XHTML in the browser, and this has some apparent efficiencies to it until you realize that any customization of that XML -> XHTML pipeline has to be done in XSLT. Have you ever tried to write, eg, a date formatter in XSLT? It's essentially impossible, and so any such formatting has to be done as a separate JavaScript pass, throwing away all the apparent cleanliness and efficiency of using XSLT with an XML payload. I believe, although maybe Luke can correct me, that this issue is why TIBCO had to deprecate all their old grid APIs in their recent 3.2 release when they added Firefox support. However, bigger picture, payload format is not that important when you have a client-side framework that supports high-level, SOA-style databinding. In SmartClient we use XPath-based binding to either JSON or XML payloads; the XPaths act on the JSON data in a manner similar to JXPath expressions on Java objects. These two examples bind a grid and form to the Yahoo Image Search service, one in XML format and the other in JSON format. They differ in one property. XML Binding JSON Binding These examples are mini-applications; if you want to see the same pattern in less code just look at the adjacent "JSON XPath Binding" example.

I discussed some of this on one of my blog posts recently. http://www.ilyasterin.com/enteprise_software/2006/09/ajaxxslt_views.html Ilya

JSON does make sense to use if only a data transfers between client and server. Mostly, it is true for heavyweight clients. However, if we need to transfer not only data, but a layout the benefits using JSON over XML becomes not so obvious. JSON presumes a predefined structure of transferred data. In case of XML, it might be an arbitrary content inserted directly to the browser DOM. = AlexaW, ajax-tutorials.com

JSON does make sense to use if only a data transfers between client and server. Mostly, it is true for heavyweight clients. However, if we need to transfer not only data, but a layout the benefits using JSON over XML becomes not so obvious.

JSON presumes a predefined structure of transferred data. In case of XML, it might be an arbitrary content inserted directly to the browser DOM.
=
AlexaW, ajax-tutorials.com

Yeah, JSON is great for AJAX calls that require raw data, that needs to be consumed by JS for calculations or other manipulation. If the data is there only for presentation purposes, then XSLT and XML should be used. I think both (JSON and XML) can be used successfuly in an application. Ilya

I really don't see the point. XML is ubiquitous and there are tools aplenty. XPATH is supported by any respectable AJAX framework and makes it ridiculously simple to access XML elements. Tools such as Prototype (AJAX framework) make it easy to access such elements and return an array as opposed to having to iterate a NodeList. I'm all for new tools but I'm having a hard time justifying retooling and the learning curve for my resources.

I really don't see the point. XML is ubiquitous and there are tools aplenty. XPATH is supported by any respectable AJAX framework and makes it ridiculously simple to access XML elements. Tools such as Prototype (AJAX framework) make it easy to access such elements and return an array as opposed to having to iterate a NodeList.

I'm all for new tools but I'm having a hard time justifying retooling and the learning curve for my resources.

That's because you haven't done a highly concurrent app with a lot of heavy AJAX lifting. XML is great for presentation formats, as was explained, that require you to transform the data. When efficiency is a must, JSON provides a more efficient data format, which you can easily eval into js. Also, when you have mutliple async calls going on, say you have auto completion or something of that nature, when each event triggers an ajax call, i'd love to see how efficiently you can do that with xml. With JSON you minimize the data transfer, plus evaling into js structure and then traversing that is way more efficient than downloading a larger XML chunk and running an XPath expression against it. Ilya

Hi, I have worked on webservices and AJAX frame work, I would like to request any one of you, to post a relevant example on JSON and Rest ful webservices, so I can understand fully. Regards venu

java net got this project, you might be interested.

jaxws-json

I have used jax-ws but it has many issues like attribute representation and issues with array, after that decided to use json web service  in google code, also my api end point audo described using this library,

http://code.google.com/p/jsonwebservice/wiki/GettingStarted