User and URL friendly object ids

Question

One normal way to serve a list of items in a web app is like this:

http://example.com/clients

Where the clients part of the url, renders a list of all clients

In previous apps clients had simple ids, that looked OK when you wanted to see more details, like:

http://example.com/clients/82

But now, I have an app where the internal ids looks like this:

http://example.com/clients/A6C1BD51-67C3-66C6-E044-00144FD25BA0

and well... that was the drop that spilled the cup. What should I do to provide user friendly ids?

One option could be generating an alias for each client:

http://example.com/clients/john-smith

Conflict?

http://example.com/clients/john-smith-austin-riverdale

But although the name is not likely to change, the address is a whole different story.

The ugly UID is mandatory, cannot be changed. I could only imagine requesting the software to maintain a secondary ID for permalinks. Should that be the best solution?

I could go back to the beginning, just simple numbers. I still do not like having something that is not human friendly, but it seems that any unique everlasting permalink cannot look nicer.

Answer 1

If you are storing unique 'usernames' in your system then why don't you make use of these to generate a permalink to the user's page like Facebook, LinkedIn, Twitter and other big players do?

E.g:

• http://twitter.com/srvikram13
• https://github.com/srvikram13
• http://in.linkedin.com/in/srvikram13
• https://www.facebook.com/srvikram13

This way the responsibility will lie with the user to choose a unique username and you need not worry about duplicate names.

Answer 2

At work we use a ruby gem for generating "slugs" (permalinks): friendly_id. The gem takes an ordered list of god ways to uniquely identify a user.

For a user those candidates could be name, age, address, zip etc, and then when one adds a new user one checks if there's already a user with that name registered if so one ads the next thing in the list to the slug , in this case age and so on until you have a unique string (and then that's saved to the db).

One use case (for me) where this kind of urls beats random strings is when you're trying to get back to a page and the only unique thing you remember is the for example the name then when you enter that into chrome's "omni box" (urlbar) it searches your history/bookmarks for a matching url.

There's a good example on the friendly_id website (the second bullet point after this heading) (if you're a little familiar with ruby)

Answer 3

I'd say you're either going to want a user friendly "nickname" or something stored along with the information, or do nothing.

As Paul says in one of the comments above; how often are users likely to manually type in the URL? They may go to http://example.com/clients, and then find the user they want there. At this point, if they visit the URL often, I'd say they're more likely to bookmark it than type that URL in each time.