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.

Let's imagine that the context by which we give objects an identity isn't confined to the application we're developing, but rather, a global context. Put another way, let's just remove the context entirely. What you now need to take into consideration is that multiple applications that could potentially serve very different purposes, can now access and use the same object because it's unique. To do this, we need to have in place the notion of universally unique identifiers. These identifiers are portable, so no matter where the object physically resides, no matter which particular application is currently using it, we know that we're dealing with the same object.

What this means, then, is that the process of object identification is different than that of address assignment. The scope, the purpose, and the value of object identification is narrow when compared to URL addresses. The sole purpose of an identifier is to give the nouns in our code a trait of uniqueness. URLs exhibit this same property to a degree, but at a different level.

When a client requests a web resource, pass the web a string. This string has much to say about what the client is actually asking for. It tells the web to go look at a particular host for the resource. It tells the web to use SSL, potentially. It tells the web that it would like the response in a particular format — JSON instead of XML. Finally, it tells the web that it would like a particular object. All of these things smudged together produce something unique — almost like an identifier — from the client's perspective. The client's idea of uniqueness is different than that of the back-end services that enable our applications. Take the response format, for instance. If my application is expecting XML but gets a JSON response, it's a different object as far as my application is concerned.

A common pattern with ajax-driven web applications is to utilize the hash portion of a URL to devise an address for a given resource. Here is a prime example of how an object's identity is only but a part of the whole in terms of "addressability". You'll notice this when you're using this type of web interface where the same object identifier can take on several forms. You'll notice, also, that the key indicator of what that object looks like is determined by part of the URL that changes. For example, #summary?id=123 displays an object 123 — so does #detail?id=123. The difference is in the view of that object. In this sample application, the views are summary and detail. But we will likely add more. Perhaps another application using the same object, 123, will introduce a whole new set of views, with a whole new set of URL addresses.

Going beyond the notion of web URLs and what they mean in terms of addresses, objects and their identities seldom sit alone in a database any more. Modern web architectures are, more often than not, composed of messaging services that aren't exposed to clients. Objects migrate from one service to another, even if only temporarily to pick up the state of another object. In this hidden expanse, we're more interested in the identifiers than web addresses that convey more than just which object is which. Here, we're not concerned so much about what the identity of the object has to say about context. Messaging endpoints aren't web clients — they're not downloading the presentation logic along with an object as we would with the browser.

With these differences in mind, there do exist some commonalities that I think are important at the design level. These objects that make up the data traversing through our systems have no fixed address. In the case of the web, the object will need more than one address out of necessity — the client needs instructions on how to display the resource. In the case of objects moving around in the form of messages, the uniqueness is important, not instructions about what to do with it.