In classic web application models, the user-agent sits between the user and the the webserver — The user-agent does not apply any business logic other than rendering the pages. With the rise of Ajax, server-side logic is moving to client, so much so that the conventional 3-tier web model is being challenged in a way that the whole presentation layer and the controller is being touted to move to the browser.
So, what happens to the veritable 404 (and other related HTTP error codes and pages)? In classic web applications, if you have a “Page Not Found” situation, you as a user “see” the associated 404 page (e.g. http://www.google.com/non_existing_page.html). However, with Ajax, it’s the Ajax engine which is suppose to capture the 404. The user sees a “pretty message” while the Ajax engine (or the library running the engine) captures the 404. For example, in scriptaculous’ javascript library, on404 is the callback handler for HTTP 404s returned from the server.
Reproducing and annotating Jesse James Garrett’s diagram from the original Ajax article comparing classic and Ajax application model further crystallizes this thought that we need a redefined set of HTTP codes to support the Ajax application model.
Image modified without explicit permission of Adaptive Path. Are they cool?
Tags: Ajax, Web 2.0, scriptaculous