Ajax: Asynchronous data retrieval using XMLHttpRequest

Oct 13, 2008

The XMLHttpRequest Object had a rather peculiar beginning. At first, Microsoft introduced an obscure little ActiveX control in Internet Explorer version 5 (IE 5) called the XMLHttp Object. Obvious, ActiveX controls are tied to IE, and shortly afterwards, Mozilla developers followed the act and came up with their own version for Mozilla 1 and Netscape 7, with the corresponding XMLHttpRequest Object. Versions of this object have been included in Safari 1.2 and Opera as well.

The XMLHttpRequest Object enables a developer to submit and receive XML documents in the background, while previously to this, they could only use hidden frames or IFrames to perform this task instead. The XMLHttpRequest object is much more complex in the way it allows developers to send and pick up data. As of April 2008, the World Wide Web Consortium standard for this object was still in progress. Because it's not standardized yet, there are still two separate ways of creating it. Web pages that use XMLHttpRequest or XMLHTTP can deal between the minor differences in implementation either by including the XMLHttpRequest object in a JavaScript wrapper, or by using an existing framework that does so. In either case, the wrapper used should detect the abilities of current implementation and work within its requirements.

The main problem solved with the use of JavaScript and XMLHttpRequest object relates to the quality and speed of the connection between a web page and its server. One of the setbacks of building a web application interface is that once a page has been downloaded to a client, the connection to the server is diminished, because attempts of dynamic interfaces involve a complete round trip of the entire page back to the server for rebuilding. This process drags the time and speed of the application, making it appear slow and unresponsive.

The traditional interface model for a web application consists of a few actions: the user requests a page from a server, which is build and delivered to the browser. The page includes a HTML form element for gathering data from the user that, once the user posts their input back to the server, enables the next page be build and served based on the input, and so on. The process revolves around the nature of the HTTP and differs from the former desktop application model of an interface which is inherently connected to the application layer. Lets look at an exemplified situation: entering a user name and a password for accessing a desktop application on a platform like Microsoft Windows. By convention, once typed in the boxes the correct user name and password, a green "tick" icon appears indicating that the user has introduced the correct user name and password. This takes place instantly as a result of the interface being developed within the application, right after the user types in the data, the application is able to check the validity and answer back. As opposed to this we have the standard behavior of the same task performed through a web interface. The user interface may look the same, with the same controllers and data forms, but on introducing data, the user needs to submit the page back to the server in order for the input to be validated. A new page would then be loaded with a message indicating whether the information was correct or not, and if not, then the user needs to go back to the previous page and re-input the information all over again.

By using JavaScript, a reasonable amount of economy can be added to a HTML page in order to give timely feedback to user interactions. There are though some issues that come with this advantage. The first is that, as the JavaScript is being delivered to the browser along with the page, the input data is opened up to checking. And this is alright for checking formats of email addresses but when it comes to passwords and user names, the exposure that the method leaves open would compromise the integrity of the input mechanism. The second issue deals with any serious logic within the page, where the interface level can not be the place were the logic resides. The logic, or processing the input, resides in the application level, founded back in the server.

The solution to these problems is represented by the XMLHttpRequest object, which is available as a native object within both Mozilla and Apple's Safari browsers. The object enables JavaScript to make HTTP requests to a remote server without the need to reload the page. Basically, HTTP requests can be made and responses received, entirely in the background and without the user experiencing any sensible interruption.

While this is a huge step forward, by providing the developer the means to achieve the goals of both a responsive user interface and preserving all the important inputs in the application level, the use of JavaScript for switching input between server and client in real time provides a performance of inputs on the server that has responses returned to the client in near-instant feedback.

Read more about it:

Ajax Technology - an Introduction
1. Standards-based presentation using XHTML and CSS
2. Dynamic display and interaction using Document Object Model
3. Data interchange and manipulation using XML and XSLT
4. Asynchronous data retrieval using XMLHttpRequest
5. JavaScript that binds everything together