Ajax: Definition vs Implementation? (XML vs JSON vs Other)

Question

AJAX actually means Asynchronous Javascript And XML. This term was derived because (as I know the story) the first people who started this process transferred data from the server to the client via XML. Lately (well ever since I've started using it actually), JSON has been around and appears to be a real alternative to XML. From my (possibly meager) tests and experience, JSON is smaller, easier, and better for transmitting data.

So my question is this: which do you use to talk to and from the server/client (and possibly why)? Or, what are the "best practices" that you have heard of (and why)?

Thanks all!

Answer 1

You can also just generate html and use that output directly into your application. XML is very verbose, where JSON requires extra attention in processing it due to security.

There is not really a 'best practice', Personally if I would choose between JSON and XML I would use JSON. Although you have some interesting query posibilities if you use XML.

Answer 2

I prefer using JSON when possible:

1. It already comes as a Javascript object, so all you need to do call eval() on it to grab all its data.
2. JSON is Javascript, so it's faster to grok for people who already know JS but don't have the intricacies of XML down.
3. In the browser, you don't have to go through the pain of parsing an XML object. (You also don't have to build one on the server, though you do have to create the JSON anyways.)
4. It's a more compact method of transferring data.

Answer 3

I gravitate towards JSON whereever possible these days. It's certainly feels lighter weight and more "natural" in conjunction with client side coding.

Security best practice: never blindly eval JSON without performing a check on the string received as you could be executing arbitrary code someone has "placed" into the JSON string.

Douglas Crockford has written a good set of security principles when working with JSON.

Answer 4

We generally prefer xml because it has some advantages over JSON like,

xml can be validated while json has no validator

no namespaces in json

xml is extensible unlike json

and json i generally considered insecure

on the other hand json itself has its advantages

json is simpler

its easier to process on the client side

debugging can be a breeze when something goes wrong

but basically it depends on what you are trying to develop, for data-oriented stuff i prefer json

Answer 5

I always smile when I see the term AJAX. I smile because I first started using the same technique long before even XMLHTTP existed, let alone AJAX.

We did the same thing as AJAX on an Intranet application in IE, but using VBScript and a Java applet instead of XMLHTTP. We used something similar to JSON, but in VBScript syntax.

Answer 6

JSON versus XML seems to be an ongoing debate - I'd rather go with JSON since it is a better fit for Web services that power mashups and AJAX widgets because it is essentially serialized Javascript objects (and thus easy to use with Javascript).

You can find some extensive comparison of the advantages and disadvantages of JSON and XML on JSON or XML, Which Format to Choose? and The AJAX response: XML, HTML, or JSON?

Answer 7

I think the debates on JSON versus XML show that JSON can be a best-practice. I don't think that client-server transmission speeds are going to go away as an issue soon, if ever. So I think that JSON will win on the issue of being smaller alone (I believe that JSON also has flexibility as to what server it can sent to but this naturally involves security issues as mentioned)

Perhaps we should start calling it"AJAWX" (Asynchronous JAvascript Without Xml).

Answer 8

My choice is JSON.

Because:

• it is much faster. You need just evaluate JSON code from response instead of parsing XML.
• it require much less of the code. eval() is less than XML parser code.
• less traffic (amount of data to transfer) between client and server as result faster handling
• it more readable

Answer 9

In theory XML would be quick good because of validation and what not. In practice you can't client side validate against a DTD or schema reasonable (or in most cases at all). Try it you'll see.

XML also suffers from its verbosity and consumption client-side. Unless you plan on using XSLT or something and directly consuming the received packet you have to chop the data up with the DOM like made.

Finally XML cannot reasonable looked at until it is complete (client-side at least) so you cannot do partial inspection. Though to be fair JSON will have challenges there as well depending on how it is structured.

Given the environment of consumption (JavaScript mostly) JSON has the obvious leg up. There is a massive discussion of this choice plus other things like YAML, CSV, base64 encoded data, HTML fragments, etc. in Chapter 4 of Ajax: The Complete Reference (http://ajaxref.com) which is just on data types. Examples prove disprove ease of handling particularly in the lesser known cases. If I had to pick one JSON would be it but frankly for some uses of Ajax small HTML fragments (since it is slap and go) is the way to do it.