Technically you can consider JSON to be a way of implementing AJAX, even though it means you don't then need to use XML at all.

Indeed, I find JSON to be a compelling way of implementing server requests; it's a lot more straightforward on the client and server side than trying to do stuff with XML and performs better.

Mark

JSON does not have any built-in way of handling character encodings; however, as you'll be using it internally to your application, you should be able to solve it yourself (Hint: just use UTF8 everywhere).

JSON potentially allows a malicious server application to execute arbitrary code on the client; this is not normally a problem because:
- client side code came from the server anyway
- The client code is running inside the browser's security model

This is largely a problem for broken server applications- which won't happen if you use a correctly made library to do JSON response assembly.

Mark

Quote:Original post by markr
JSON potentially allows a malicious server application to execute arbitrary code on the client

The &#106avascript JSON parser at json.org does some validation of the input to avoid any code that is executable instead of a data structure, so it should be safer than plain 'eval'. (Why does the word "[J]avacript" always get lowercased in these forums?)</small><br><br>XML and JSON are unable to represent non-tree structures (e.g. a certain object repeated in two places, or &#111;ne object containing itself as a child) - YAML can handle them fine, as well as language-specific things like classes of objects, which makes it the &#111;nly choice (of those three) in certain situations. YAML is also (at least in my opinion) easier to read than the others, so it's useful for things like configuration files &#111;n the server. But for anything &#111;n the web, it's far harder to parse YAML &#111;n the client than the others, because XML is handled by the browser and JSON is handled by the browser's &#106avascript engine, while a full YAML parser requires much more code. (You can actually handle a subset of YAML using a JSON parser (i.e. 'eval'), since <a href="http://redhanded.hobix.com/inspect/yamlIsJson.html">all JSON is valid YAML</a>, but then you might as well call it JSON instead of YAML.)<br><br>As for JSON vs XML, I've always stuck with JSON because it's just faster and easier to use in the languages I've been using (Perl and &#106avascript). And you can still call it AJAX if you consider the X to mean 'XMLHttpRequest' (which handles plain text (e.g. JSON) fine) instead of 'XML', and get exactly the same client-side effects.

JSON vs XML:

Use what is appropriate for the job. XML is very universal and an excellent choice when it comes to storing data that may be used in several different ways. I think the real power of XML comes in with the use of XSLT.. amazing stuff can happen there. However, few websites have the need to represent data in multiple ways.

You may also consider XML as an easier method of manipulating the DOM. The very thought of serving up an XML document containing only data and having the client transform it and insert it into the DOM makes me giddy :D (yes, I'm that geeky) Much easier than dealing with an object and writing out the HTML in &#106avascript.<br><br>If you are using the data in ways that don't involve representing it as HTML, JSON is obviously more lightweight and may be the logical choice. Learning both is important too. As I said in the beginning: Use what is appropriate for the job.