Trying to go for the jugular here. AJAX utilizes XMLHttpRequest class for its asyncronous communication, Flash Player 5 – 8 use XML class, and Flash Player 8.5 utilizes URLLoader (and friends). Let’s compare the things that are different. Request headers, for example, are very similiar for all 3.
Aborting the Call
XMLHttpRequest has abort. XML does not. URLLoader has close which effectively does the same thing.
Syncronous & Asyncronous (everyone freeze vs. I’ll get back to you)
XMLHttpRequest has the ability to be syncronous or asyncronous. XML & URRLoader do not, they are always asyncronous.
Event Handling
XMLHttpRequest has a onReadyStateChange event that fires when the loading state of the object has changed, at which point the developer will check the readyState property to determine which of those 5 different states it has changed to (uninitialized, loading, loaded, interactive, complete).
XML has 2 events, onData and onLoad. XML, if created as an instance, is always initialized. XML is either loading XML to and from the server, or it’s not, via the loaded property.
URLLoader has 7 events for various states & times of the loading operation.
Return Data
XMLHttpRequest gets its text response data in the responseText property.
XML gets its text response data as the first parameter to the onData event, at which point you handle it, or parse it, set loaded to true, and call onLoad with a true as the first parameter.
XMLHttpRequest gets its xml response data as the responseXML property.
XML, as it is an XML-DOM object already, is ready to be accessed by DOM methods as soon as the onLoad method fires with a true as the first parameter, meaning the data was successfully downloaded & parsed.
XMLHttpRequest gets browser responses via the status property.
XML doesn’t; you have to parse them from onData. There are some common return values found in the XML.status property.
URLLoader gets an httpStatus event.
URLLoader’s complete event is complex, however, in that different requests could of been made (a simple HTTP request, a binary stream you intend to parse, a GET/POST action that will have URL encoded variables attached, or waiting to get raw XML). Each request operation has a class to handle the common operations for each.
Conclusions
The fact that both XMLHttpRequest & URLLoader have abort functionality makes them much better than XML. Not being able to abort requests wastes bandwidth, as well as server-processing. Additionally, I have yet to see a conclusive report on how much bandwidth is being saved/added to a web application from going to a many small requests/responses with fewer page refreshes model vs. a few large request/responses with more page refreshes model.
While I peronally cannot see a reason why you would ever want to intentionally have code block, thus locking not only your script running, but also your GUI, I do know a lot of developers who do. XMLHttpRequest scores a high mark via this boilerplate aspect in the ability be syncronous or not.
XMLHttpRequest & URLLoader both score high marks in having the ability to see the http status code, where you can’t (natively anyway) with XML.
URLLoader I think wins here merely from the fact that you know what the heck is going on. The myriad of events, with the information each event object contains, gives you a lot more context to what is happening with your request. Knowing when it’s done downloading, when you’ve got a piece of data that’s started to download, being notified of an http status code, getting an ioError when she blows up, getting an open event when the data has started to download (after the data you have sent is done sending), getting more than 1 progress event for longer loads with a current and total amount of bytes, if known. No one wants to know about securityErrors, but they are there.
XMLHttpRequest has you continually check a property on each status change; that in itself doesn’t really give much context as to what is going on, and you must investigate this yourself with code vs. being told.
XML? It either works or it doesn’t, and you have sparse tools to know what really happened.
If I had a choice, I’d choose to use URLLoader to do asyncronous loading of data on the web.
Sources
I haven’t really looked into it in detail, do you happen to know if URLLoader supports full access to HTTP headers? And am i able to send HTTP request headers (things like authorization, content-range etc come to mind)
Hell yeah. Check out flash.net.URLRequest and flash.net.URLRequestHeader. Exactly what you are looking for.
Link to AS3 docs on Livedocs.
Groovy!
on the synchronous vs asynchronous front, dont forget that XMLSocket ( a 4th approach) offers a fully statefully connection with the server
Aye, and so does flash.net.Socket… but these are strictly request/response API’s I’m talking about, not persistent sockets. AJAX isn’t persistent, and neither is XML nor URLLoader. So, to be fair to the AJAX camp, I used those types of classes. XMLSocket & Socket make it… well, unfair. I went for the 3 stroke knife kill, not the headshot.