Advanced Requests and Responses in Ajax

An anonymous reader writes "The Web is no longer a place where simple applications are tolerated; 'users have become more advanced, customers expect robustness and advanced error reporting, and managers are fired because an application goes down 1 percent of the time. It's your job then, to go beyond a simple Ajax application that requires a more thorough understanding of XMLHttpRequest.' This DevWorks article tries to help developers use Ajax to build a solid foundation in which an application handles errors and problems smoothly."

Comments

Re:AJAX?

[mmkkbb]

It's the rather scary idea of using JavaScript on a webpage to run XML-RPC requests to a remote server and update the local page, allowing for flashy stuff like Google Maps and GMail that does not require a new page to be loaded.

Too bad it requires JavaScript!

Re:AJAX?

[DeveloperAdvantage]

If you want a one hour summary, take a listen to our most recent audiobook at http://www.developeradvantage.com/products.html . It's free for now.

Re:AJAX?

[codesurfer]

Not the most definitve source, but this should give you an adequate overview:

http://en.wikipedia.org/wiki/AJAX

Pretty sparse

[Gopal.V]

The document is pretty much ranks in the category of 30 second ajax tutorials. It would have been better if the document has explained how you were supposed to handle concurrent XmlHttpRequests - a problem I am faced with. Yesterday, I noticed the new Y! libs released had - transaction ids for Ajax requests. I've been using closures in javascript to maintain the context info, but this way sounds much better.

Any decent webdev entering the field should know about http status codes, HEAD requests and all that. Also it should be noted that article didn't even mention how many times state 3 is hit for a particular request - I got caught by that one once.

Re:Users..

[nuttzy]

If high availability is key then you'd better not be using anything beyond HTML.

Uh... how about having an app degrade nicely? In most cases it's not that tough. So for the large majority that can take advantage of your whiz bang web app, go ahead and use AJAX (where it makes sense) and just be sure to have it degrade nicely for browsers that are not ajax aware and then also for browsers that are not handling javascript.

Corrected URL

[RealProgrammer]

The download link in TFA has an error. To get the code from the article, use:

http://download.boulder.ibm.com/ibmdl/pub/software /dw/web/wa-ajaxintro3_ajax-xhr_adv.zip

Taking the "%20" away from the final "/" made it work.

(There should be no spaces in the URL.)

Re:AJAX?

[DeveloperAdvantage]

Thanks. Sometimes I really don't understand the censoring, I mean mod system here. Our audiobooks are currently freely downloadable, we have no advertising on our side, and it seems reasonable and on topic that if someone asks about Ajax to point them to our material. After all, this whole thread is about an article from a huge, profitable corporation. Maybe instead of audiobooks, I should call them "audicles", and then it will be ok to mention them when people are looking for information.

Anyway, thanks again.

Re:AJAX?

[slamb]

It's what most web people have been doing for years now anyways. using html, javascript and a server side scripting like PHP together to make a website. in a way you could call slashdot a AJAX type of site.

You'd be wrong. I don't believe slashdot uses any Javascript, except maybe some ad stuff. And even if it did, that's not a good definition. The point of Ajax is updating the client's display with new data from the server without reloading the entire page. This is why Ajax is so trendy - these pages are more pleasant to use because they respond more quickly, and without unrelated parts of the display going away and coming back or causing everything to scroll away from what you were looking at.

Ajax accomplishes this with the XMLHttpRequest() object. (It's a misnomer - XML doesn't have to be involved at all.) It's just a way to issue a request and execute some code when it completes (by success, failure, or timeout). That code can update a status bar, add some text to the page, or do something more sophisticated.

I would prefer the JSON way

[moria]

Using JSON, JavaScript can load data from any address, when XMLHttpRequest requires you to stay in the same domain. Besides, JSON is JavaScript native and is therefore much easier to consume, for example, using MochiKit. As for the generator, it is trivial to convert native data to JSON data in a wide range of programming languages, including all the major server side scripting languages, like Python and Java. Yahoo has released a lot of their APIs on JSON and some excellent Python WebApp Framework has built-in support to speak to the client scripts in JSON.

Re:I would prefer the JSON way

[brpr]

There's nothing to it, it's just a subset of the Javascript literal syntax which happens to have a lot of library/community support (i.e. you don't have to roll your own Perl parser/generator library, or whatever).

Re:AJAX?

[Biffa]

The core concept of AJAX is to use Javascript in the browser to make requests to the server and then update the browser without having to load a new web page. This is accomplished by using the XMLHTTPRequest object which is available in one form or another in the lastest major browsers. This concept isn't particularly new (I worked on a project in 1999 that used a Java Applet to do the work that XMLHTTPRequest now does). However, what is new is that the technology is available natively in the major browsers, and can be used to make web-based applications more interactive and user friendly, without requiring any additional plug-ins. However, AJAX is currently a hot buzzword and way over-hyped. Anyone who already has solid Javascript skills and knows a server side scripting language should be able to pick up AJAX in a couple of hours. Eventually, there will be a nice OSS AJAX library available that will hide the details, but for right now, there's nothing better than an intimate understanding of the XMLHTTPRequest object.

Re:No longer tolerating what??

[Run4yourlives]

Where's the ajax on slashdot?

Click on the word "Sections" in the menu....

Re:AJAX Privacy and Security?

[AKAImBatman]

One thing about Javascript is that it is very aware of the client's environment--we can use it to determine screen size, colour depth, browser type, browser history and so forth.

The browser history is not available for security reasons. Off the top of my head, I don't remember if anything more than the screen resolution can be obtained. Really, you're not getting back anything useful. Just a lot of statistics that the Javascript uses to do its job.

Until the introduction of the XMLHTTPRequest object, developers were limited in how they could bring this information into the server.

Hidden IFrames have all the power of XMLHTTPRequest. There is a "click" in Internet Explorer, but all other cues are missing.

Browsers like Firefox can limit the use of javascript to do popo-up ads, alter toolbars and such, but I see nothing regarding security control of the XMLHTTPRequest object.

Depends on the browser, but many browsers chose the path provided by Java Applets. i.e. An AJAX application can only ship back data to the server it was downloaded from. That means that the server needs to act as a proxy if it wants to send calls elsewhere on the Internet.