No Fixed Address

All content out there on the web has a fixed address. But the objects that reside in the implementation of these web resources do not. At least not in a URL-sense. These are objects that live in the database, in cache, or in the web server's memory, as part of an intermediary step toward the finished product that is ultimately delivered to the client. What these objects do have that strikes a similarity with URL-thinking is a unique identifier. These identifiers tell us that this object has it's own state, unique to itself in some context. The context in which these objects are unique is usually constrained to the application. For instance, the primary key that identifies a row in a database table is a common object identifier. The context in which we're assigning identifiers to objects is growing more important, as time moves on, because there is a growing need that the applications we develop integrate seamlessly with one another.

When To Use Ajax

Take a look around the web today. You'll be hard-pressed to find many interfaces that don't incorporate at least some aspect of ajax. The term ajax has grown to mean more than just asynchronous javascript API requests, although that is a huge part of it.

Ajax can add a new level of interactivity to a web application user interface. This can be done by making changes to an existing interface or by implementing the principles of ajax straight from the get go. Typically, however, you aren't going to want to use asynchronous API calls from an existing javascript application that doesn't already. Especially not if it is stable. There are other aspects of the ajax style that can still be applied in these scenarios.

Many javascript toolkits are in existence today and most provide widget support in one form or another. Widgets are really no different from those found in APIs for desktop environments. The only obvious difference is that these widgets are drawn in the browser using javascript and CSS. Developers get a few things for free when implementing the widgets found in javascript toolkits. First, you get the free design, which, isn't easy to do. Especially if themes are of concern. Second, many of these widgets are configurable and can offer the end user subtle behavioral interaction improvements. The overall user interface has been made "smoother".

One of the great things about the web is addressability. Opponents of ajax say that ajax applications take this attribute away. And, in most cases, they are right because applications that use asynchronous javascript API calls exclusively, have no URIs that users can see and manipulate. They can't copy and paste links. This is one of the key reasons why the web is the size that it is today.

There is, however, a middle ground. Just because a web application implements ideas found in ajax doesn't mean that it can't have useful URIs. Even if the set of useful URIs is a small one, it is still useful to have for the user's sake. Obviously, these URIs become less important if the web application is an internal application that doesn't live on the web.

Addressability Lost Within The Realm Of Ajax

With RESTful APIs and applications, and with HTTP in general, addressability plays a huge role. With web applications that project an Ajax user interface, this addressability is typically gone. There is no notion of URI as far as the end user is concerned. This is because Ajax web applications often have a single URI; the application itself. From this point forward, the end user navigates through the various application states while all the addressable URIs are contacted beneath the fancy Ajax interfaces. If you are an end user using these types of applications, do you necessarily care? That would depend what you are using the application for and the type of user you are. For most end users, if the use interface is well designed, the addressability of the resources involved with the application are a non-issue. Even developers, the type one would think would be interested in the underlying application data, might be too enthralled with how useful the user interface is. If the user interface of an Ajax web application is poorly designed, things change. The data at the other end of the URI suddenly becomes much more interesting.

In more traditional web applications, the ones without the fancy asynchronous javascript toolkits, the URI of almost every resource is accessible from the address bar in the web browser. This is obviously the benefit to having addressable resources in a web application. The URIs are immediately apparent to the end user via the web browser address bar. With Ajax web applications, end users cannot point there web browser to a specific URI and expect the application to behave accordingly. This, I find, to be one of the more annoying drawbacks to using Ajax web applications. Although the user experience of Ajax web applications is improving at an ever increasing rate, the sacrifice of addressability, a powerful concept, has to be made.

But does addressability really need to be lost completely in Ajax web applications? Just because the URI isn't in its' normal location, the web browser address bar, doesn't mean the end user can't know about it. In fact, many web applications that provide an Ajax user interface will also provide a public RESTful API used by that interface, complete with documentation. However, this doesn't solve the problem of the end user that doesn't care about API documentation and just wants page X of the application to appear when they point their web browser to URI Y. I think something like this could potentially work. There would have to be two separate RESTful APIs; one for the application resource data, and one for the user interface. The user interface would interest the end users because they could use these URIs to point the web browser to a specific application state. These user interface application URIs wouldn't even need to be reflected in the web browser address bar. As long as the current user interface application state is advertised somewhere in the user interface, it could work. And it would be incredibly useful.