AJAX Without XML HTTP Requests

January 19, 2011

What is AJAX?

Asynchronous JavaScript and XML - AJAX - is what you use to create truly dynamic websites. Ajax is the bridge between application and presentation layers, facilitating lightning fast, instant application of data from the end user to the host and back to the end user. It dynamically changes the data displayed on the page without disrupting the end user or bogging down the client. Although the name is misleading, it is used as a term for any process that can change the content of a web page without unnecessarily reloading other parts of the page.

What are XML HTTP requests?

Passing information from your server to your end user's browser is handled over HTTP in the form of HTML. The browser then takes that info and formats it in a way the end user can view it easily. What if we want to change some of the data in the HTML without loading a whole new HTML document? That's where XML comes in. Your web page needs to tell the browser to ask for the XML from the server; luckily, all browsers have a function called XmlHttpRequest(). Once it's called, it will poll the server for XML data.

Why shouldn't you use XML HTTP requests?

A long time ago, in a galaxy far, far away, Microsoft invented the XmlHttpRequest() object for Microsoft Exchange Server 2000. As with all first generation technologies, everyone wanted to use it, and some people implemented it differently. IE didn't even have native support until 2006, and there are still some discrepancies in various browsers when studying the OnReadyStateChange event listener. There is also an issue with cross-domain requests. When the internet was young, JavaScript hackers would steal users' identity by pulling information from secure websites and posting it to their own, stealing bank account numbers, credit cards, etc. Now that the internet has grown up a bit, people with large networks and many servers have found use for sending data across domains, but it's still not possible with XML HTTP requests.

What's an Alternative?

Using JavaScript, you can create client side scripts whose source is built with server side scripts, passing variables in the URL. Here's an example of a basic web page with local JavaScript, a few checkboxes for human interaction, and a table with some information that we want to change. View source on the page below to see the outline.


Looking at the three JavaScript functions, the first (clearTags) automatically clears out the checkboxes on load, the second (check(box)) makes sure that only one box is checked at a time, the third (createScript) is the interesting one; it uses the createElement() function to create an external JavaScript, the source of which is written in PHP. I have provided a sample script below to explain what I mean. First, we get the variable from the URL using the $_GET super global. Then, we process the variable with a switch, but you might use this opportunity to grab info from a database or other program. Finally, we print code which the browser will translate to JavaScript and execute.

<code>&lt;?PHP
//First we get the variable from the URL
$foo=$_GET['foo'];
//Here's the switch to process the variable
switch ($foo){
case 'foo' : print "var E=document.getElementById('data'); E.innerHTML='bar'; "; break;
case 'fooo' : print "var E=document.getElementById('data'); E.innerHTML='barr'; "; break;
case 'ffoo' : print "var E=document.getElementById('data'); E.innerHTML='baar'; "; break;
case 'ffooo' : print "var E=document.getElementById('data'); E.innerHTML='baarr'; "; break;
default : print "var E=document.getElementById('data');
E.innerHTML='unknown'; ";
}
?&gt;
</code>

-Kevin

Comments

January 19th, 2011 at 2:12pm

If we're talking about viable best-practice alternatives to XmlHttpRequest(), I'd like to suggest the jQuery javascript library, and specifically jQuery ajax: http://api.jquery.com/jQuery.ajax/. It acts as a wrapper for XmlHttpRequest() and can handle a variety of usage scenarios with various data types. My personal favorite is JSON, which is more lightweight and human-readable than xml.

Passing variables or data via the querystring in the URL is standard practice for GET requests, but represents a security risk when transmitting sensitive information. Since the script is hitting a URL, that hit would be recorded on a webserver's access logs, so by extension, any data in the query string would also get recorded. This is not a big deal if the data is something like a record ID, but could be a big deal if transmitting data like passwords, bank accounts, ssn's etc. The proper way to send data in these scenarios is to use a POST request instead, which jQuery can handle. To my knowledge, there is no way to initiate an HTTP POST with the above approach.

I would not recommend placing javascript code in a server-side script in this fashion because it is a poor separation of concerns with regards to code maintainability. Most web developers expect to both find and work with javascript on the client side of things. As a practical example, suppose the above script is more complicated than simply changing the HTML string of a particular DOM element. A sufficiently complicated script will take time to develop and debug properly, and this process would be made unnecessarily more complicated by having the code reside on a server-side script. My recommendation would be to keep all client code defined on the client side, and have the server scripts do only what they are required to do--in this case, to return a string based on an input string. Then, the client side parses the return data and acts accordingly.

January 28th, 2011 at 2:41pm

I agree, this method is not for sending secure data, but I think it does have some place in your web programming arsenal. Think of it as a remote procedure call. The client requests information from a remote server using the GET method, this information is stored in a cookie and can be accessed by any program that knows how to process them. The remote server can then respond with data which can be parsed by JavaScript once received.

 

July 5th, 2011 at 8:14am

It will be interesting to see how the battle between JSON and XML will play out as the defacto choice for web serices, I noticed twitter and Amazon have migrated their API's from xml to json as well, mainly because xml is so bloated.

July 25th, 2011 at 12:19pm

I see JSON as better for small amounts of data, like cookies or scripts, and XML for larger amounts of data, like fully fledged documents. If I were to make a blog site, I would save the actual blogs in XML or XHTML, that way I could include a bit of formatting in the blog itself, for comments on the blog or forum posts I would be more apt to using JSON. I feel that most APIs run better in JSON or JSONP, because you are usually receiving small snipets of data saved as variables, rather than full documents. Another advantage of JSON is that the format is naturally compatible with the browser, there is no need to translate the information client-side.

Leave a Reply

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <pre>, <blockcode>, <bash>, <c>, <cpp>, <drupal5>, <drupal6>, <java>, <javascript>, <php>, <python>, <ruby>. The supported tag styles are: <foo>, [foo].
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Comments

January 19th, 2011 at 2:12pm

If we're talking about viable best-practice alternatives to XmlHttpRequest(), I'd like to suggest the jQuery javascript library, and specifically jQuery ajax: http://api.jquery.com/jQuery.ajax/. It acts as a wrapper for XmlHttpRequest() and can handle a variety of usage scenarios with various data types. My personal favorite is JSON, which is more lightweight and human-readable than xml.

Passing variables or data via the querystring in the URL is standard practice for GET requests, but represents a security risk when transmitting sensitive information. Since the script is hitting a URL, that hit would be recorded on a webserver's access logs, so by extension, any data in the query string would also get recorded. This is not a big deal if the data is something like a record ID, but could be a big deal if transmitting data like passwords, bank accounts, ssn's etc. The proper way to send data in these scenarios is to use a POST request instead, which jQuery can handle. To my knowledge, there is no way to initiate an HTTP POST with the above approach.

I would not recommend placing javascript code in a server-side script in this fashion because it is a poor separation of concerns with regards to code maintainability. Most web developers expect to both find and work with javascript on the client side of things. As a practical example, suppose the above script is more complicated than simply changing the HTML string of a particular DOM element. A sufficiently complicated script will take time to develop and debug properly, and this process would be made unnecessarily more complicated by having the code reside on a server-side script. My recommendation would be to keep all client code defined on the client side, and have the server scripts do only what they are required to do--in this case, to return a string based on an input string. Then, the client side parses the return data and acts accordingly.

January 28th, 2011 at 2:41pm

I agree, this method is not for sending secure data, but I think it does have some place in your web programming arsenal. Think of it as a remote procedure call. The client requests information from a remote server using the GET method, this information is stored in a cookie and can be accessed by any program that knows how to process them. The remote server can then respond with data which can be parsed by JavaScript once received.

 

July 5th, 2011 at 8:14am

It will be interesting to see how the battle between JSON and XML will play out as the defacto choice for web serices, I noticed twitter and Amazon have migrated their API's from xml to json as well, mainly because xml is so bloated.

July 25th, 2011 at 12:19pm

I see JSON as better for small amounts of data, like cookies or scripts, and XML for larger amounts of data, like fully fledged documents. If I were to make a blog site, I would save the actual blogs in XML or XHTML, that way I could include a bit of formatting in the blog itself, for comments on the blog or forum posts I would be more apt to using JSON. I feel that most APIs run better in JSON or JSONP, because you are usually receiving small snipets of data saved as variables, rather than full documents. Another advantage of JSON is that the format is naturally compatible with the browser, there is no need to translate the information client-side.

Leave a Reply

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <pre>, <blockcode>, <bash>, <c>, <cpp>, <drupal5>, <drupal6>, <java>, <javascript>, <php>, <python>, <ruby>. The supported tag styles are: <foo>, [foo].
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.