Ajax Data Transfer Methods - XMLHttpRequest Alternatives

XMLHttpRequest is not the only way to implement Ajax - in fact it is not even the most popular one. Take a quick look at the various transport methods in Ajax...

XMLHttpRequest

This is the W3C standard - most modern browsers supports this - browsers like...

ActiveX(XMLHTTP)

This is the preferred method in Internet Explorer. Currently this is the most used method for ajax calls - due to the simple fact that IE has the majority market share. This is basically a different name for XMLHttpRequest - except for the initilization, all the API calls are the same as in XMLHttpRequest(thank God for that).

IE did not have a native XMLHttpRequest object(dispite the fact that they invented the concept). XMLHttpRequest was first introduced to the world as an ActiveX control in Internet Explorer 5.0. Fortunatly, they have native support for XMLHttpRequest from IE 7 onwards.

IFrame

This is used as a fallback for older browsers by some ajax libraries. In this method you load the URL in a (typically) hidden iframe element. Once the iframe has compleated loading, you can read the contents of the iframe. That way, you have a working Ajax system even in very old browsers.

One of the main advantages of this method is that it does not have the cross-domain issue(also known as the same origin restriction).

Image Source

This is not a popular transfer method - in fact, I have seen it in use only once. The basic concept is that you can point an image's src to a server-side script. That script can do the necessary operation on the server and then return the image.

The major disadvantage of this method is that data can only be passed to the server - the server cannot pass data back to the client. Well, it is possible - if you set a cookie on the server and then read it in the client side. Trust me, you don't need that kind of headaches - Ajax development is enough trouble as it is.

But it has a few advantages too...

Script Tag

This uses the same principle as the Image method - the only difference is that you use a script instead of an Image tag. That way, the server can return data to the client side as well.

This is a very popular method in the mashup scene. The main reason is this method don't have the cross domain issue. For example del.icio.us offers this as a choice to get data from their site.

This method is also possible using a stylesheet - but I don't want to go into that.

Non Javascript methods

Flash

Flash can be used to get data from the server and pass it to the javascript code.

Java Applets

I am sure that Java Applets can be used for this too - can anyone confirm this?

Related Topics...

Comments

Anonymous at 08 Oct, 2007 02:06
Image Source? A example, please.
Reply to this.
David Golightly at 08 Oct, 2007 06:05
This is an old hack - see zingzoom.com/ajax/ajax_with_image.php and www.webreference.com/programming/ajax_tech2/
Reply to this.
Anonymous at 14 Nov, 2007 01:07
Thanks
Reply to this.
ajaxus at 10 Oct, 2007 02:16
quite usefull information!
thanks for sharing this!

with these two: iframe and image source you took me back 4 years ago :)

Cheers
Reply to this.
Anonymous at 09 Nov, 2007 04:18
It's NOT TRUE that you can read the contents of an IFrame from a different domain (not on the modern browsers). Try it.
Reply to this.
Aalaap at 09 Nov, 2007 09:00
Given a choice, I'd always use a script tag with a custom-generated script on the server side. It's cross-domain friendly and I can trigger events a bit easier. No messy XMLHttpRequest and callback registers!
Reply to this.
Binny V A at 16 Jan, 2008 11:24
Firefox 3 has cross domain call support. Hopefully that will get into other browsers as well.
Reply to this.
TAP at 01 Apr, 2008 02:41
You can see all these transports in action at ajaxref.com/ch2/ There are others including style which are quite silly but possible. In short anything that can trigger a GET can be used for a 1-way request and 2-way if cookies are enabled. Cross domain limitations are in place here and there and as Binny mentions browsers are now circumventing this.

Another reason to consider alternate transports to XHRs is the likely trend for XHR disabling which is quite easy to perform in IE.
Reply to this.
Anonymous at 05 Aug, 2008 09:02
I wish this article had more than just one sentence about the option of using Flash as a bridge for XHR communication.

I've released flXHR (pronounced flex-er) at flxhr.flensed.com/ which is a javascript+SWF solution to the cross-domain communication problem. It implements an identical API to the native XHR object. So it can easily be used as a drop-in replacement for the XHR object, meaning it's incredibly easy (~3 lines of code) to adapt into all the major JS frameworks that already understand how to speak XHR API.

The best part is that Flash's model of cross-domain security uses a server opt-in concept, which means that the x-domain free for all can be avoided if your application needs to control more closely who can access your content (of course, you can have "*" policies which open it all the way up if necessary -- like FLICKR and YOUTUBE).
Reply to this.
Comment

Please dont enter you comments in this form - this is a fake form to confuse spamming bots. The next form is the real one.




Comment




Comment Formating : HTML tags a, strong, em, b, i, code, pre, p and br allowed. Other tags will be shown as code(< will become &lt;). Urls, Line breaks will be auto-formated.