Django - URL design and best practices for identify one object

Question

Im actually working in a django project and I'm not sure about the best format of the URL to access into one particular object page.

I was thinking about these alternatives:

1) Using the autoincremental ID => .com/object/15

This is the simplest and well known way of do that. "id_object" is the autoincremental ID generated by the database engine while saving the object. The problem I find in this way is that the URLs are simple iterable. So we can make an simple script and visit all the pages by incrementing the ID in the URL. Maybe a security problem.

2) Using a <hash_id> => .com/object/c30204225d8311e185c3002219f52617

The "hash_id" should be some alphanumeric string value, generated for example with uuid functions. Its a good idea because it is not iterable. But generate "random" uniques IDs may cause some problems.

3) Using a Slug => .com/object/some-slug-generated-with-the-object

Django comes with a "slug" field for models, and it can be used to identify an object in the URL. The problem I find in this case is that the slug may change in the time, generating broken URLs. If some search engine like Google had indexed this broken URL, users may be guided to "not found" pages and our page rank can decrease. Freezing the Slug can be a solution. I mean, save the slug only on "Add" action, and not in the "Update" one. But the slug can now represent something old or incorrect.

All the options have advantages and disadvantages. May be using some combination of them can some the problems. What do you think about that?

Answer 1

I think the best option is this:

.com/object/AUTOINCREMENT_ID/SLUG_FIELD

Why?

First reason: the AUTOINCREMENT_ID is simple for the users to identify an object. For example, in an ecommerce site, If the user want to visit several times the page (becouse he's not sure of buying the product) he will recognize the URL.

Second reason: The slug field will prevent the problem of someone iterating over the webpage and will make the URL more clear to people.

This .com/object/10/ford-munstang-2010 is clearer than .com/object/c30204225d8311e185c3002219f52617

Answer 2

IDs are not strictly "iterable". Things get deleted, added back, etc. Over time, there's very rarely a straight linear progression of IDs from 1-1000. From a security perspective, it doesn't really matter. If views need to be protected for some reason, you use logins and only show what each user is allowed to see to each user.

There's upsides and downsides with every approach, but I find slugs to be the best option overall. They're descriptive, they help users know where there at and at a glance enable them to tell where they're going when they click a URL. And, the downsides (404s if slugs change) can be mitigated by 1) don't change slugs, ever 2) set up proper redirects when a slug does need to change for some reason. Django even has a redirects framework baked-in to make that even easier.

The idea of combine an id and a slug is just crazy from where I'm sitting. You still rely on either the id or the slug part of the URL, so it's inherently no different that using one or the other exclusively. Or, you rely on both and compound your problems and introduce additional points of failure. Using both simply provides no meaningful benefit and seems like nothing more than a great way to introduce headaches.