Django - дизайн URL и лучшие практики для идентификации одного объекта

Question

Я на самом деле работаю в проекте django, и я не уверен, какой формат URL лучше использовать для доступа к одной конкретной странице объекта.

Я думал об этих альтернативах:

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

Это самый простой и известный способ сделать это. «id_object» - автоинкрементный идентификатор, сгенерированный ядром базы данных при сохранении объекта. Проблема, которую я нахожу таким образом, заключается в том, что URL-адреса просты итеративны. Таким образом, мы можем сделать простой сценарий и посетить все страницы, увеличив идентификатор в URL. Возможно проблема с безопасностью.

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

"hash_id" должен быть некоторым буквенно-цифровым строковым значением, сгенерированным, например, с помощью функций uuid. Это хорошая идея, потому что она не повторяется. Но генерация «случайных» уникальных идентификаторов может вызвать некоторые проблемы.

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

Django поставляется с полем «slug» для моделей, и его можно использовать для идентификации объекта в URL. Проблема, которую я нахожу в этом случае, заключается в том, что слизняк может измениться со временем, создавая неработающие URL. Если какая-то поисковая система, например Google, проиндексировала этот неработающий URL, пользователи могут перейти на страницы «не найдены», и рейтинг нашей страницы может снизиться. Замораживание Слизняка может быть решением. Я имею в виду, сохранить слаг только на действие «Добавить», а не на «Обновить». Но слизняк теперь может представлять что-то старое или неправильное.

Все варианты имеют свои преимущества и недостатки. Может быть, с помощью их комбинации могут возникнуть проблемы. Что вы думаете об этом?

Answer 1

Я думаю, что лучший вариант такой:

.com/object/AUTOINCREMENT_ID/SLUG_FIELD

Почему?

Первая причина: AUTOINCREMENT_ID прост для пользователей, чтобы идентифицировать объект.Например, на сайте электронной коммерции, если пользователь хочет посетить страницу несколько раз (поскольку он не уверен в покупке продукта), он распознает URL.

Вторая причина: поле slug предотвратит проблему, связанную с тем, что кто-то перебирает веб-страницу, и сделает URL более понятным для людей.

Этот .com/object/10/ford-munstang-2010 понятнее, чем .com/object/c30204225d8311e185c3002219f52617

Answer 2

идентификаторы не являются строго «повторяемыми».Вещи удаляются, добавляются обратно и т. Д. Со временем очень редко происходит прямая линейная последовательность идентификаторов от 1 до 1000.С точки зрения безопасности это не имеет большого значения.Если по какой-либо причине представления должны быть защищены, вы используете логины и показывает только то, что каждому пользователю разрешено видеть каждому пользователю.

У каждого подхода есть свои плюсы и минусы, но я считаю, что слагы - лучший вариант.в общем и целом.Они наглядны, они помогают пользователям знать, где они находятся, и с первого взгляда позволяют им узнать, куда они идут, когда нажимают URL-адрес.И, минусы (404 с, если слагы меняются) могут быть смягчены с помощью 1) не меняйте слагов, когда-либо 2) устанавливайте правильные перенаправления, когда слаг действительно нужно менять по какой-то причине.Django даже имеет встроенный фреймворк для перенаправления, чтобы сделать это еще проще.

Идея объединить id и слизняк просто безумна от того, где я сижу.Вы по-прежнему полагаетесь либо на идентификатор , либо на часть URL-адреса slug, так что по своей сути он ничем не отличается от использования одного или другого исключительно.Или вы полагаетесь на то и другое и усугубляете свои проблемы и вводите дополнительные точки отказа.Использование обоих просто не дает значимого преимущества и кажется просто отличным способом вызвать головную боль.

Answer 3

Никто не говорил о поле UUID ( справочная страница поля модели django ), которое может быть хорошей реализацией "хеш-идентификатора".Я думаю, что вы можете иметь URL-адрес, например:

.com/object/UUID/slug

Он не позволяет отображать заказ в URL, если этот заказ не имеет отношения.*

в зависимости от соответствующей информации, которую вы хотите получить в URL