Mastering Ajax, part 8th: Using XML in requests and responses

Ajax client/server communication can be tricky

Introduction: In the previous article in this series, you saw how AJAX applications formatted requests to the server in XML format. Also understand why this is not a good idea in most cases. This article focuses on an approach that is indeed a good idea in most cases: returning an XML response to a client.

I don't really like writing articles that basically tell you what not to do. Most of the time, that would be a very stupid article. I'm going to explain something in the first half of the article, and then in the second half, it's a bad idea to use the kind of technology you just learned. To a large extent, the previous article was a case in point (if you missed that installment, check out the links in resources), which taught you how to use XML as the request data format for an AJAX application.

Hopefully this article will make up for the time you spent learning XML requests. In Ajax applications, there are few reasons to use XML as a format for sending data, but there are many reasons why the server should send XML back to the client. Therefore, the knowledge about XML that you learned in the previous article will eventually reflect some value in this article.

The server (sometimes) cannot respond to too many requests

Before delving into the technology to get an XML response from a server, you need to understand why it is a good idea to have the server send XML to respond to requests (and this is different from the client sending an XML request).

Client sends a request with a name/value pair

Recalling the previous article, you will know that in most cases the client does not need to use XML because they will send the request using a name/value pair. Therefore, you may send a name like this: Name=jennifer. Simply add a "ampersand" (&) between successive name/value pairs to put it together, just like this: name=jennifer&job=president. With simple text and these name-value pairs, clients can easily request multiple values from the server. There is little need to use the extra structure provided by XML (and the extra overhead it entails).

In fact, all the reasons to send XML to the server can be grouped into the following two basic categories:

The server accepts only XML requests. In such cases, you have no choice. The basics described in the previous installment should have given you the tools you need to send such a request.

You are calling a remote API that accepts only XML or SOAP requests. This is actually a special case of the previous one, but it's worth mentioning it alone. If you want to use an API from Google or Amazon in an asynchronous request, there are some special considerations. In the next installment, I'll look at these considerations and give some examples of sending such requests to the API.

The server could not send a name/value pair (in a standard way)

When you send a name/value pair, the Web browser sends the request, the platform rings the request, and hosts a server program that converts those name/value pairs into data that the server program can easily handle. In fact, each server-side technology-from Java™servlet to PHP to Perl, Ruby on rails---allows you to invoke multiple methods to get values based on names. Therefore, getting the Name property is a trivial matter.

This situation does not lead us in another direction. If the server uses string name=jennifer&job=president to answer an application, the client does not have any standardized and easy way to split each pair into names and values. You must resolve the returned data manually. If the server returns a response made up of a name/value pair, such a response is as difficult to interpret as using a semicolon, a vertical bar, or any other non-standard formatted character.

For you, this means that there is no easy way to use plain text in the response, so that the client obtains and interprets the response in a standard way, at least when the response contains more than one value. If your server is just going to send back the number 42, plain text is a good choice. But if the server is going to send back the TV show Lost, what about the recent ratings of Alias and Six Degrees? Although there are a number of ways to send this response in plain text (Listing 1 shows some examples), none is an extremely simple way to do some processing without a client, nor is it a standardized approach.

Listing 1. Ratings of the server response (different versions)

show=Alias&ratings=6.5|show=Lost&ratings=14.2|show=Six% 20Degrees&ratings=9.1
Alias=6.5&Lost=14.2&Six%20Degrees=9.1
Alias|6.5|Lost|14.2|Six%20Degrees|9.1

Although it is not hard to find a way to split these response strings, the client will have to parse and split the strings based on semicolons, equals, vertical bars, and symbols. This is not a way to write robust code that makes it easy for other developers to understand and maintain.