June 06, 2005, 9:45 AM — In the beginning there was the URL. A harmless, unremarkable naming convention which, in a very short period of time, has become as commonplace as a telephone number. The very structure and shape of a URL speaks to us. It whispers - no, that is too weak a statement - it positively shouts 'CLICK ME! CLICK ME WHY DON'T YOU! Click me and see what happens. Click me because chances are, something interesting will happen. Go on, click me...'
And we humans oblige. We hover around URLs like moths around a gas lamp. We find them irresistible. Our very conceptualizations of digital information and digital business logic have become so wrapped up in the concept of a URL that we no longer find their presence remarkable. On the contrary, applications or information resources that do not feature clicking on URLs have become the remarkable ones.
Given our reliance on URLs, we are amazingly tolerant of broken ones. In the early days of the Web, many library science types and information processing types were of the opinion that the Web would not take off because it took such a casual attitude to broken hypertext links. How could anyone use a system in which there was no guarantee that the thing linked to even exists?
We all know what happened. It took users two seconds to figure out that a "404" was some sort of computer-speak for "try somewhere else" and users did exactly that. They treated 404s as minor inconveniences, not showstoppers. Life went on and the Web grew from strength to strength, widespread broken links notwithstanding.
It can be argued (and I am going to argue it) that the Web of the future will have to be a little more careful with broken URLs. I do not mean to suggest that something significant needs to happen in the Web infrastructure. I do mean to suggest that programmers of Web applications are going to have to be more careful though.
The mainstay of Web applications to date have been human-to-process applications. Simply put, they have been based on the assumption that a tolerant human being is clicking the buttons in a browser trying to make things happen. If a link doesn't work, a human user might just go get a pizza and try again later or try somewhere else. Humans are resourceful that way.
These days, the situation is becoming more complex as a variety of process-to-process applications emerge on the Web. Companies such as Google and Amazon and Flickr are making URLs available to programs, as opposed to humans. These URLS are intended to be used as building blocks in the development of larger applications. A portal that incorporates information from Amazon's catalog, a GIS application that utilizes Google maps, a community application that utilizes Flickr and so on.
These URLs are finding their way into Web applications. These Web applications in turn, may make URLs available to other applications and so on. The fun starts when, through changes in the business environment or changes in the functionality of applications, these URLS have to change. Then what? Applications are so much less forgiving than humans. An application, faced with a URL that does not work, is capable of doing a variety of silly things ranging from failing silently (giving the user a wrong answer perhaps), through to going down in flames with an unhelpful error message.
Simply put, URLs that get embedded into software need to be managed through time much more carefully than URLs that are only ever clicked on by humans. We are clearly in the first generation of composite applications on the Web. As we build out the first generation of these, we will be laying down a layer of invisible glue, a
