Django - Diseño de URL y mejores prácticas para identificar un objeto

Question

Estoy trabajando en un proyecto django y no estoy seguro del mejor formato de la URL para acceder a una página de objeto en particular.

estaba pensando en estas alternativas:

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

Ésta es la forma más sencilla y bien conocida de hacer eso. "id_object" es el ID autoincremental generado por el motor de la base de datos al guardar el objeto. El problema que encuentro de esta manera es que las URL son iterables simples. Por lo tanto, podemos crear un script simple y visitar todas las páginas incrementando el ID en la URL. Tal vez un problema de seguridad.

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

El "hash_id" debe haber algún valor de cadena alfanumérica, generada por ejemplo, con funciones UUID. Es una buena idea porque no es iterable. Pero generar identificadores únicos "aleatorios" puede causar algunos problemas.

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

Django incluye un campo "babosa" para los modelos, y que puede ser utilizado para identificar un objeto en la URL. El problema que encuentro en este caso es que la babosa puede cambiar en el tiempo, generando URL rotas. Si algún motor de búsqueda como Google indexó esta URL rota, los usuarios pueden ser guiados a páginas "no encontradas" y nuestro rango de página puede disminuir. Congelar el Slug puede ser una solución. Quiero decir, guarde la babosa solo en la acción "Agregar", y no en la de "Actualizar". Pero la babosa ahora puede representar algo viejo o incorrecto.

Todas las opciones tienen ventajas y desventajas. Puede estar usando alguna combinación de ellos algunos de los problemas. ¿Qué piensas de eso?

Answer 1

creo que la mejor opción es la siguiente:

.com/object/AUTOINCREMENT_ID/SLUG_FIELD 

¿Por qué?

Primer motivo: el AUTOINCREMENT_ID es simple para que los usuarios identifiquen un objeto. Por ejemplo, en un sitio de comercio electrónico, si el usuario desea visitar varias veces la página (porque no está seguro de comprar el producto) reconocerá la URL.

Segundo motivo: El campo slug evitará el problema de que alguien itere sobre la página web y hará que la URL sea más clara para las personas.

Este .com/object/10/ford-munstang-2010 es más claro que .com/object/c30204225d8311e185c3002219f52617

Answer 2

IDs no son estrictamente "iterable". Las cosas se eliminan, se vuelven a agregar, etc. Con el tiempo, raramente hay una progresión lineal directa de las ID de 1-1000. Desde una perspectiva de seguridad, realmente no importa. Si las vistas deben protegerse por alguna razón, utiliza inicios de sesión y solo muestra lo que cada usuario puede ver a cada usuario.

Hay ventajas y desventajas con cada enfoque, pero creo que las babosas son la mejor opción en general. Son descriptivos, ayudan a los usuarios a saber dónde y, a simple vista, les permiten saber a dónde van cuando hacen clic en una URL. Y, las desventajas (404s si las babosas cambian) pueden ser mitigadas por 1) no cambiar babosas, nunca 2) configurar redirecciones apropiadas cuando una babosa necesita cambiar por alguna razón. Django incluso tiene un marco de redirecciones integrado para facilitar aún más las cosas.

La idea de combinar una identificación y una babosa es una locura desde donde estoy sentado. Todavía confía en la id o, la parte slug de la URL, por lo que no es inherentemente diferente utilizar una u otra exclusivamente. O bien, confía en ambos y agrava sus problemas e introduce puntos de falla adicionales. El uso de ambos simplemente no ofrece ningún beneficio significativo y parece ser una excelente forma de provocar dolores de cabeza.