In modern web applications you will regularly notice that page urls contain the ID of the thing you are viewing. An example might be /product/135 which would point to the 135th product added to an online store.

The ID usually comes directly from the database. Each time a product is added, the ID column is incremented by 1 and creates a new number.

This works well in most situations, but consider a multi-level application. Recently I’ve been involved with working on an issue tracker. The system includes areas called projects, and within each project you then have issues.

So the urls for the application might look something like /project/12/issue/246 which if we stuck to the incremental method above would mean we were viewing the 246th issue added to the system.

But wouldn’t it be nice if the number was actually the 246th issue added to that project? It would give a much clearer idea of what we were looking at just from the url.

And that is the point of this article. Sometimes, although it’s easier to stick to database IDs, we should push the boat out and make our urls and items specific to the area we are in.

As far as the database schema, it adds a small amount more complexity because we then have another column (number) to keep track of, but the benefits far outweigh this.

A few examples of where it might be useful are players in a team, pupils in a class or year, photos in a gallery or cars in a race.

So now each time I start work on a new app, I look to see if I can make the items relevant to their container rather than to the system as a whole, and it adds just a little more clarity to a users experience of the product.