Developing with AJAX, communication protocols

I and several other developers from YouService met with Ross Dargahi, from Zimbra, for dinner a week ago and discussed how Zimbra is doing AJAX development. One of the main ideas I took from the meeting dealt with how the client and server should communicate. If you look at a lot of the AJAX tutorials out there you will find quite a bit of emphasis put on using xml as the transport language. However, there are other options that I would like to go over.

XML is a logical choice, it’s agnostic in terms of technology. There is no assumption about anything with the client. You could have a fat client, webapp, webservice, you name it, and as long as the client understands the apis it can deal directly with the your server. The whole mashup craze likes this a lot. Any third party developer can hook up to your system. Whether you allow this is a business decision and requires monitoring and authentication on the server side to enforce policies. In terms of flexibility, using xml is at the top of the heap. The downside, if you’re creating a webapp is that you’ve now got to put a whole lot of logic into the client side code. You need to be able to take that xml, parse it, and turn it into a meaningful datastructure in order to do something with it. This is where a lot of the difficulty in developing AJAX applications comes in.

Lets look at the other end of the spectrum. You’re developing a webapp, so why not have the server just send back html. This is an option that you don’t see discussed too much, but it does have its place. With this option the client side code just needs to fetch the result from the server and insert it into the page, usually using a div.innerhtml. This is the fastest way to develop. The client side code becomes very simple and easy to debug. The downside to this approach is that outside developers are very limited in their ability to plug into your services. Your webapp is now tightly coupled with the server and vice versa. Data reuse on the client side becomes problematic as well. If you have a single piece of data, say username, that you would like to display in multiple places on the page you would have to make mulitple requests to the server to fetch that data for each position. The client is now incredibly dumb and doesn’t know anything about what data it has so it can’t reuse it.

Both xml and html have their drawbacks, but getting back to the dinner, Ross strongly advised using JSON as the protocol. JSON supplies a very nice middle ground. It’s open enough, with parsers written for almost every language. You can define and expose interfaces to outside developers. It also makes the client side coding easy enough that it’s doable, but strong enough that you can put real logic in the client. JSON allows you to focus on the the fun part of developing, not the parsing of xml into datastructures and catching all the errors.

Having worked with all three models, I now feel very strongly about using JSON. It just has the right mix of flexibility and ease of development.