Object serialization involves defining some kind of identifier for each object. For shelve or sqlite, we need to define a string key for each object. A RESTful web server makes the same kinds of demands to define a workable key that can be used to unambiguously track down objects. A simple, surrogate key can also work out for a RESTful web service identifier. It can easily parallel the key used for shelve or sqlite.

What's important is this idea: cool URIs don't change. See http://www.w3.org/Provider/Style/URI.html.

It is important for us to define a URI that is never going to change. It's essential that the stateful aspects of an object are never used as part of the URI. For example, a microblogging application may support multiple authors. If we organize blog posts into folders by the author, we create problems for shared authorship and we create larger problems when one author takes over another author's content. We don't want the URI to switch when a purely administrative feature, such as the ownership, changes.

A RESTful application may offer a number of indices or search criteria. However, the essential identification of a resource or object should never change as the indices are changed or reorganized.

For relatively simple objects, we can often identify some sort of identifier – often a database surrogate key. In the case of blog posts, it's common to use a publication date (as that can't change) and a version of the title with punctuation and spaces replaced by _ characters. The idea is to create an identifier that will not change, no matter how the site gets reorganized. Adding or changing indexes can't change the essential identification of a microblog post.

For more complex objects that are containers, we have to decide on the granularity with which we will refer to these more complex objects. Continuing the microblog example, we have blogs as a whole, which contain a number of individual posts.

The URI for a blog can be something simple like this:

/microblog/blog/bid/ 

The top-most name (microblog) is the overall application. Then, we have the type of resource (blog) and finally, an ID, bid, for a specific instance.

The URI names for a post, however, have several choices:

/microblog/post/title_string/ 
/microblog/post/bid/title_string/ 
/microblog/blog/bid/post/title_string/ 

The first URI doesn't work well if multiple posts have the same title. In this case, something would have to be done to make the title unique. An author may see their title made unique with an extra _2 or some other decoration. This is often undesirable.

The second URI uses the blog ID (bid) as a context or namespace to ensure that the Post titles are treated as unique within the context of a blog. This kind of technique is often extended to include additional subdivisions, such as a date, to further shrink the search space. This example is a little awkward, because the classification, post, is followed by the blog's ID.

The third example uses an explicit class/object naming at two levels: blog/bid and post/title_string. This has the disadvantage of a longer path, but it has the advantage of allowing a complex container to have multiple items in distinct internal collections.

Note that REST services have the effect of defining paths to resources in persistent storage. The URIs must be chosen with an eye toward clarity, meaning, and durability. A cool URI doesn't change.

Let's learn about the different layers of REST services.