Monday, January 30th, 2006

Ideal Ajax data format?

Category: Ajax, JavaScript, Programming

The quirky PPK at quirksmode asks:

Once you’ve succesfully fired an AJAX request, what sort of response should the server give? An XML document? An HTML snippet? A JSON string which is converted to a JavaScript object? Or something else? In this entry I’d like to discuss the three formats, with examples, and ask you which format you’ve used in your practical AJAX applications.

We are a little late linking to the article (its from mid December), but its worth reading for the lengthy discussion that follows. In the end, the answer is a resounding “it depends”. XML gives you the most flexibility and can be consumed by other services, HTML is the easiest to get going with, and JSON can get around the same-server issue. Do you prefer one most of the time or just go with what works for your current task? Or maybe you go with one of the other options, such as a custom text format or generated javascript to be evaled by the client?

Posted by Rob Sanheim at 9:30 am

3.9 rating from 26 votes


Comments feed TrackBack URI

For little amount of data, JSON brings a 50% gain in content size.
With big amounts, the limit reachs about 25% of size gain.
The most important benefit affects both server and client sides:

No overhead in creating a DOM doomed to be serialized so it takes the http road.
No overhead in feed a DOMParser to expose the received xml content as a DOM.

With JSON, just feed eval() with it, and keep going.

XML remains the standard for machine2machine communication, but when it comes to browser consumption, better reduce computing time to the max the user gets his data at once. Not to mention accessing the JSONed data is way more straightforward that exploring a DOM from the javascript pov.

Comment by Pascal — January 30, 2006

[…] [via Ajaxian] […]

Pingback by Aarakast » Bestes Ajax-Datenformat — January 30, 2006

I think returning pure html markup has a serious limitation of restricting your response target to an element on the page (typically a rectangle defined by a div element.) XML can be too verbose at times, but makes for a more reusable API. But at the present moment I’m going with JSON because the “parsing” seems less error-prone and I free to alter the current HTML as I please while handling the response (I know it’s similar to what can be done wiht XML). I guess I find JSON to be more productive than XML.

Comment by Sergio Pereira — January 30, 2006

I can’t wait till services like Yahoo! provide XMLP through their APIs.

All the same cross domain goodness of JSON wrapped in angle brackets :)

Comment by Dave Johnson — January 30, 2006

I use and advocate working with XML responses from server. Responses of XML can be transformed/rendered using XSL, and re-rendered on a resort, without a new request. Rendering with Javascript is in the long run poorer solution. Another advantage is that when transforming XML with XSL, the broswer is executing the parsing; and the broswer possess better capabilities and perform better than Javascript.

I even make all my requests in XML; without exception, pure XML back and forth…

Comment by Hakan Bilgin — January 30, 2006

Why not use content negotiation and output more than one format?

Make it required that clients have to send an Accept HTTP header specifying their preference for the output they wish to receive. Start with support for one format, and then add support for other formats as necessary.

Comment by Dan Kubb — January 30, 2006

I prefer XHTML as combination of HTML and XML. Works really great for dual-mode (Ajax and non-Ajax) components.

Comment by Michael Jouravlev — January 30, 2006


Comment by a — March 1, 2006

Leave a comment

You must be logged in to post a comment.