Using XML format for request

Even casual Ajax developers will notice the x in Ajax, and realize that it stands for XML. XML is one of the most popular data formats in any programming medium, and offers real advantages for server responses in asynchronous applications. In this article, we'll see how servers can send XML in response to a request.

We really can't do any significant programming today without running across XML. Whether you're a Web page designer considering the move to XHTML, a Web programmer working with JavaScript, a server-side programmer using deployment descriptors and data binding, or a back-end developer investigating XML-based databases, the eXtensible Markup Language (XML) is everywhere. Then it is no surprise that, XML is considered one of the core technologies that lie under Ajax.

However, this opinion reflects the poor choice of names for the core object used in Ajax applications, XMLHttpRequest more than it does technical reality. In other words, most people think XML is a core part of Ajax because they assume that the XMLHttpRequest object actually always uses XML. But that's not the case, and the reasons why are the subject of the first part of this article. We can see that in most Ajax applications, XML rarely makes an appearance at all.

XML does have real uses in Ajax, and XMLHttpRequest allows for these as well. There's certainly nothing keeping us from sending XML to a server. Apart from normal data, XML is also a usable format. In this article; we'll look at how to do that. More importantly, though, we'll talk about why we might use XML for our request format, and where, it shouldn’t be used.

XML: Is it really there at all?

It's easy to make assumptions about Ajax applications and their usage of XML; both the technology name (Ajax) and the core object it uses (XMLHttpRequest) imply the use of XML, and we'll hear XML linked with Ajax applications all the time. However, this perception is simply wrong, and if we want to really know the stuff when it comes to writing asynchronous applications, we need to know that the perception is wrong -- and, better yet, know why it's wrong.

XMLHttpRequest: Poor names and HTTP

One of the worst things that can happen to a technology is for it becomes so hot that changing core pieces of it becomes impossible. That's exactly what's happened with XMLHttpRequest, the basic object used in Ajax apps. It sounds like it's designed to either send XML over HTTP requests, or perhaps make HTTP requests in some sort of XML format. Whatever the object's name sounds like, though, what it actually does is simply provide a way for your client code (usually JavaScript in your Web page) to send an HTTP request. More than that, nothing is there.

Thus, it would be nice to simply change XMLHttpRequest's name to something more accurate, like HttpRequest, or perhaps simply Request. However, millions of developers are now throwing Ajax into their applications, and because we all know that it takes years, if not decades -- for the majority of users to move to new browser versions like Internet Explorer 7.0 or Firefox 1.5, such a move is simply not feasible. The end result is that will be sucked up with XMLHttpRequest, and it's up to developers to realize that the thing is just poorly named.

It's somewhat telling that one of the best known fallback methods for dealing with a browser (especially on Windows) that doesn't support XMLHttpRequest is to use the Microsoft IFRAME object. Hardly sounds like XML, HTTP, or even a request, does it? Obviously, all those things might be involved, but this should simply make clear the fact that the XMLHttpRequest object is a lot more about making requests without requiring a page reload than it is about XML, or even HTTP.

The requests are HTTP, not XML

When we write code in a Web page to communicate with a server, whether it's using Ajax or a normal form POST or even a hyperlink, we're just talking HTTP.

Given that pretty much all Web communication between browsers and servers takes place through HTTP, the idea that XML is somehow the transport or technology used by XMLHttpRequest under the covers just doesn't make any sense. It's certainly possible for XML to be sent in the HTTP request, but HTTP is a very precisely defined standard that isn't going away any time soon. Unless you're specifically using XML in your request, or the server is sending you a response in XML, there's nothing but plain old HTTP used in the XMLHttpRequest object. So the next time someone tells you, "Yeah, it's called XMLHttpRequest because it uses XML behind the scenes," just smile and patiently explain to them what HTTP is, and let them know that while XML can be sent over HTTP, XML is a data format, not a transfer protocol.

Using XML (for real)

So far, I've told you about all the places where XML isn't used in Ajax. But the x in Ajax and the XML in XMLHttpRequest are still very real, and you may have several options for using XML in Web applications. we'll look at the basic options first, and then really go in to detail in the rest of this article.

Options for XML

In our asynchronous apps, we'll find two basic applications of XML:

• To send a request from a Web page to a server in XML format


• To receive a request from a server in your Web page in XML format

The first of these, to send a request in XML; requires formatting request as XML, either using an API to do so or just stringing together the text, and then sending the result to a server. In this option, the main job at hand is to construct the request in a way that complies with the rules of XML, and that can be understood by the server. So the focus is really on the XML format; once we have the data to be sent, and just need to wrap it up in XML semantics. The rest of this article focuses on this use of XML in your Ajax applications.

The second of these options, to receive a request in XML; requires you to take a response from a server, and extract the data from XML (again, using either an API or more of a raw coding approach). In this case, focus is on the data from the server, and it just so happens that we've got to pull that data out of XML to use it in any constructive way. This is the subject of the next article in this series, and we'll go deeper then.

An introductory warning

Before we go to the details of using XML, a short cautionary word is in order: XML is not a small, fast, space-saving format. As we'll see in the next several sections and in the next article in this series, there are some great reasons to use XML in this context, and some advantages that XML has over plain text requests and responses (especially for responses). However, XML is almost always going to take up more space and be slower than plain text, because several tags and semantics required for XML in messages.

If we want to write a tremendous fast application that feels like a desktop app, XML might not be the best place to start. If we begin with plain text, and find a specific need for XML, then that's great; however, if we use XML from the beginning, we are certainly slowing down application's responsiveness. In most cases, it's faster to send plain text, using name/value pairs like name=haki -- than to turn the text into XML like this: Think of all the places where using XML adds time: wrapping the text in XML; sending across extra information (note that we didn't have any surrounding elements, an XML header, or anything else that would probably be part of a more realistic request); having the server parse the XML, generate a response, wrap the response back in XML, and send it back to a Web page; and then webpage parsing the response and finally using it. So learn when to use XML, but don't start out by thinking that it's going to make application faster in many situations; rather, it adds flexibility, as we'll begin to talk about now.

XML from the client to the server

Let's look at using XML as the format to send data from a client to a server. First, we'll see how to do this technically, and then spend some time examining when this is a good idea, and when it's not.

Sending name/value pairs

In about 90 percent of the Web apps we write, we'll end up with name/value pairs to send to a server. For example, if a user types their name and address into a form on your Web page, you might have data like this from the form:

firstName=Haki
lastName=P
street= Rajendra Dall Mill Road 
city= Vijayawada 
state=Andhra Pradesh
zipCode=520012  

If you were just using plain text to send this data to a server, you might use code that looks something like listing below. (This is similar to an example used in the first article in this series.)

Listing.. Sending name/value pairs in plain text

function callServer() 
{ 
// Get the city and state from the Web form 
var firstName = document.getElementById("firstName").value; 
var lastName = document.getElementById("lastName").value; 
var street = document.getElementById("street").value; 
var city = document.getElementById("city").value; 
var state = document.getElementById("state").value; 
var zipCode = document.getElementById("zipCode").value; 
// Build the URL to connect
var url = "noteUser.php?firstName=" + escape(firstName) +
"&lastName=" + escape(lastName) +
"&street=" + escape(street) + "&city=" + escape(city) 
+ "&state=" + escape(state) + "&zipCode=" + escape(zipCode); 
  // Open a connection to the server 
xmlHttp.open("GET", url, true); 
  // Set up a function for the server to run when it's done 
xmlHttp.onreadystatechange = confirmUpdate; 
  // Send the request 
xmlHttp.send(null); } 

Converting name/value pairs to XML

The first thing we need to do if we need to use XML as a format for data like this is to come up with some basic XML format in which to store the data. Obviously, your name/value pairs can all turn into XML elements, where the element name is the name of the pair, and the content of the element is the value:

<firstName>Haki</firstName> 
<lastName>P</lastName> 
<street>Rajendra Dall Mill Road</street> 
<city>Vijayawada</city> 
<state>Andhra Pradesh</state> 
<zipCode>520012</zipCode>    

Of course, XML requires that we have a root element, or, if we're just working with a document fragment (a portion of an XML document), an enclosing element. So you might convert the XML above to something like this:

<address>
<firstName>Haki</firstName>
<lastName>P</lastName>
<street>Rajendra Dall Mill Road</street>
<city>Vijayawada</city>
<state>Andhra Pradesh</state> 
<zipCode>520012</zipCode>
</address> 

Now we're almost ready to create this structure in your Web client, and send it to the server

Communication, of the verbal kind

Before we’re ready to start tossing XML over the network, we need to make sure that the server and script -- to which you send data actually accepts XML. For many of us it may not seem as a point to be noted, but for beginners, I thought it would be better to mention here only.

In fact, we need to take two steps to ensure that the data sent in XML will be received correctly:

1. Ensure that the script to which XML is sent, accepts XML as a data format.


2. Ensure the script will accept the particular XML format and structure in which data is sent.

Both of these will probably require actually talking to a human being, so fairing warning! Seriously, if it's important that you be able to send data as XML, most script writers will appreciate you; so just finding a script that will accept XML shouldn't be that hard. However, you'll still need to make sure that your format matches what the script expects. For example, suppose the server accepts data like this:

<profile> 
<firstName>Haki</firstName> 
<lastName>P</lastName> 
<street Rajendra Dall Mill Road</street> 
<city>Vijayawada</city> 
<state>Andhra Pradesh</state> 
<zip-Code>520012</zip-Code> 
</profile>  

This looks similar to the XML above, except for two things:

1. The XML from the client is wrapped within an address element, but the server expects the data to be wrapped within a profile element.


2. The XML from the client uses a zipCode element, while the server expects the zip code to be in a zip-code element.

In the grand scheme of things, these really small points are the difference between the server accepting and processing your data, and the server crashing miserably and supplying your Web page and probably its users -- with a cryptic error message. So we need to figure out what the server expects, and mesh the data we send into that format. Then only we are ready to deal with the actual technicalities of sending XML from a client to a server.

Sending XML to the server

When it comes to sending XML to the server, we'll spend more of your code taking your data and wrapping it XML than you will actually transmitting the data. In fact, once you have the XML string ready to send to the server, you send it exactly as you would send any other plain text; check out listing below to see this in action.

Listing.. Sending name/value pairs in XML

function callServer() 
{ 
// Get the city and state from the Web form 
var firstName = document.getElementById("firstName").value; 
var lastName = document.getElementById("lastName").value; 
var street = document.getElementById("street").value; 
var city = document.getElementById("city").value; 
var state = document.getElementById("state").value; 
var zipCode = document.getElementById("zipCode").value;  
var xmlString = "<profile>" +  " <firstName>" + escape(firstName) + "</firstName>" +  " <lastName>" + escape(lastName) + "</lastName>" +  " <street>" + escape(street) + "</street>" +  " <city>" + escape(city) + "</city>" +  " <state>" + escape(state) + "</state>" +  " <zip-code>" + escape(zipCode) + "</zip-code>" +  "</profile>";   
// Build the URL to connect to 
var url = "noteUser.php";   
// Open a connection to the server 
xmlHttp.open( "POST", url, true);   
// Tell the server you're sending it XML 
xmlHttp.setRequestHeader("Content-Type", "text/xml");  
// Set up a function for the server to run when it's done 
xmlHttp.onreadystatechange = confirmUpdate;   
// Send the request 
xmlHttp.send(xmlString);
//Generally for text, This would be null or blank.
} 

Much of this is self-explanatory with just a few points worth noting. First, the data in your request must be manually formatted as XML. That's a bit of a letdown after three articles on using the Document Object Model, isn't it? And while nothing forbids you from using the DOM to create an XML document using JavaScript, we'd then have to convert that DOM object to text before sending it over the network with a GET or POST request. So it turns out to be easier to simply format the data using normal string manipulation. Of course, this introduces room for error and typographical mistakes, so one need to be extra careful when you write code that deals with XML.

Once XML is constructed, open a connection in largely the same way as it would be when sending text. I tend to prefer using POST requests for XML, since few browsers places a length limitation on GET query strings, and XML can get pretty long; we'll see that Listing above switches from GET to POST accordingly. Additionally, the XML is sent through the send() method, rather than as a parameter tacked on to the end of the URL you're requesting. These are all fairly trivial differences, easy for adjusting.

We need to write one entirely new line of code:

xmlHttp.setRequestHeader("Content-Type", "text/xml");  

This isn't hard to understand: it just tells the server that we're sending it XML, rather than plain old name/value pairs. In either case, we send data as text, but use text/xml here, or XML sent as plain text. If you just used name/value pairs, this line would read:

xmlHttp.setRequestHeader("Content-Type", "text/plain"); 

If we forget mentioning Request type, server code will not work properly.

Once we get all this put together, all you need to do is call send() and pass in the XML string. The server will get our XML request, and (assuming we've done your pre-work) accept the XML, parse it, and send you back a response. That's really all there is to it -- XML requests with just a few changes of code.

Sending XML: Good or bad?

Before leaving XML requests (and this article) for XML responses, let's spend some real time thinking about the sensibility of using XML in your requests. I've already mentioned that XML is by no means the fastest data format in terms of transfer, but there's a lot more to think about.

XML is not simple to construct

The first thing we need to realize is that XML is just not that easy to construct for use in requests. As we observed in listing above, our data quickly becomes pretty convoluted with the semantics of XML:

var xmlString = "<profile>" + 
" <firstName>" + escape(firstName) + "</firstName>" + 
" <lastName>" + escape(lastName) + "</lastName>" + 
" <street>" + escape(street) + "</street>"
+ " <city>" + escape(city) + "</city>"
+ " <state>" + escape(state) + "</state>" 
+ " <zip-code>" + escape(zipCode) + "</zip-code>" + 
"</profile>";    

This might not seem so bad, but it's also an XML fragment that has only six fields. Most of the Web forms developed will have ten to fifteen; although we won't use Ajax for all of your requests, it is a consideration. we're spending at least as much time dealing with angle brackets and tag names as you are with actual data, and the potential to make little typing is tremendous.

Another problem here is that, as already mentioned; we will have to construct this XML by hand. Using the DOM isn't a good option, as there aren't good, simple ways to turn a DOM object into a string that you request can be sent. So working with strings like this is really the best option; but it's also the option that's hardest to maintain, and hardest to understand for new developers. In this case, we constructed all the XML in one line; things only get more confusing when this is done in several steps.

For Requests, Nothing is added by XML

Beyond the issue of complexity, using XML for our requests really doesn't offer us much of an advantage, if any over plain text and name/value pairs. Consider that everything in this article has been focused on taking the same data we could already send using name/value pairs refer first listing in article and sending it using XML. At no point was anything said about data that you can send with XML that we could not send using plain text; that's because there almost never is anything that we can send using XML that you can't send using plain text.

And that's really the bottom line with XML and requests: there's just rarely a compelling reason to do it. We'll see in the next article in this series that a server can use XML for some things that are much harder to do when using plain text; but it's just not the case with requests. So unless you're talking to a script that only accepts XML (and there are some out there), we're better off using plain text in almost every request situation.

In conclusion

We should definitely feel like we're starting to get the XML in Ajax figured out. We know that Ajax apps don't have to use XML, and that XML isn't some sort of magic bullet for data transfer. We should also feel pretty comfortable in sending XML from a Web page to a server. Even more importantly, we know what's involved in making sure that a server will actually handle and respond to your requests: we've got to ensure that the server script accepts XML, and that it accepts it in the format that we're using to send the data over.

We also should have a good idea now of why XML isn't always that great a choice for a data format for requests. In future articles, you'll see some cases where it helps, but in most requests, it simply slows things down and adds complexity. So while I'd normally suggest that you immediately start using the things you learned in an article, I'll instead suggest that you be very careful about using what you've learned here. XML requests have their place in Ajax apps, but that place isn't as vastly as its thought of.

In the next article in this series, you'll look at how servers can respond using XML, and how your Web applications can handle those responses. Happily, there are a much larger number of reasons for a server to send XML back to a Web app than the other way around, so you'll get even more use out of that article's technical detail; for now, be sure you understand why XML isn't always a great idea -- at least for sending requests. We might even want to try and implement some Web apps using XML as the data format for requests, and then convert back to plain text, and see which seems both faster and easier to us.