For an application I'm building in my spare time I am looking for (arguably) the correct way to return data from an XmlHttpRequest. Options I see are:

  • Plain HTML. Let the request format the data and return it in a usable format. Advantage: easy to consume by the calling page. Disadvantage: Very rigid, stuck with a fixed layout.

  • XML. Let the request return XML, format it using XSLT on the calling page. Advantage: the requested service is easily consumed by other sources. Disadvantage: Is browser support for XSLT good enough?

  • JSON. Let the request return JSON, consume it using javascript, render HTML accordingly. Advantage: easier to 'OO-ify' the javascript making the request. Disadvantage: Probably not as easy to use as the previous two options.

I've also thought about going for option one while abstracting the view logic in the called service in such a way that switching in and out different layouts would be trivial. Personally I think this option is the best out of three, for compatibility reasons.

While typing this, I got another insight. Would it be a good idea to allow all three response formats, based on a parameter added to the request?

+1  A: 

As usual, it depends. Do you actually need the flexibility of being able to change the view layout?

John Topley

I think this sort of depends on the level of "ajaxyness" your app is going to have. If your front end is a "rich client", al'a gmail, I'd go with the JSON solution, as you'd have to solve the problem of having client side view generation anyway. If you're using ajax sparingly, to provide simple messages to the user, update a few fields now and then, etc, then I'd go with option 1, since most of your view logic is already on the server.

Erlend Halvorsen

Different response format shouldn't be difficult to produce. JSON works best for me, i like to keep OO in js, and don't know how to parse xml well :)

+1  A: 

If you're looking for a quick solution that should work with most available frameworks, I'd go for JSON. It's easy to start with and works.

If you're trying to build a larger application that you're going to extend (in terms of size or maybe your own API for 3rd party extensions) I'd go for XML. You could write a proxy to provide the information in JSON or HTML too, but having XML as the main source is definitly worth the time and effort while building the app.

Like @John Topley said: it depends.

+2  A: 

I'd agree with John Topley - it depends on the application. There's a good article on quirksmode that discusses the advantages and disadvantages of each format that you might want to read:

Ian Oxley

I think trying to use XmlHttpRequest will be a huge headache, unless its the type of headache you don't mind - to do it properly you're almost reinventing the wheel. Then again, people like to reinvent wheels in their spare time, just to say, "Hey, I did it". Not me...

I would get a framework like prototype or Extjs, that has alot of data loading functions built in for XML and JSON, plus you'll get more predictable results, as the frameworks have event handlers to make sure your XmlHttpRequest succeeded or failed. Plus you get support for all the various browsers.