Django - 识别一个对象的 URL 设计和最佳实践答案

【问题标题】：Django - URL design and best practices for identify one objectDjango - 识别一个对象的 URL 设计和最佳实践
【发布时间】：2012-02-22 18:39:10
【问题描述】：

我实际上在一个 django 项目中工作，我不确定访问特定对象页面的 URL 的最佳格式。

我正在考虑这些替代方案：

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

这是最简单且众所周知的方法。 “id_object”是数据库引擎在保存对象时生成的自增ID。我以这种方式发现的问题是 URL 是简单的可迭代的。所以我们可以制作一个简单的脚本，通过增加 URL 中的 ID 来访问所有页面。可能是安全问题。

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

“hash_id”应该是一些字母数字字符串值，例如使用 uuid 函数生成。这是一个好主意，因为它不可迭代。但是生成“随机”的唯一 ID 可能会导致一些问题。

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

Django 带有一个用于模型的“slug”字段，它可以用来识别 URL 中的对象。我在这种情况下发现的问题是 slug 可能会随着时间的推移而改变，从而生成损坏的 URL。如果某些搜索引擎（如 Google）已将这个损坏的 URL 编入索引，用户可能会被引导至“未找到”页面，我们的页面排名可能会降低。冷冻蛞蝓可能是一个解决方案。我的意思是，只在“添加”操作中保存 slug，而不是在“更新”操作中。但是 slug 现在可以代表旧的或不正确的东西。

所有选项都有优点和缺点。可能使用它们的某种组合可能会出现一些问题。你怎么看？

【问题讨论】：

看看这个问题的网址，你就会得到答案:-)

标签： django url identifier

【解决方案1】：

我认为最好的选择是：

.com/object/AUTOINCREMENT_ID/SLUG_FIELD

为什么？

第一个原因： AUTOINCREMENT_ID 便于用户识别对象。例如，在一个电子商务网站中，如果用户想要多次访问该页面（因为他不确定是否购买该产品），他将识别该 URL。

第二个原因： slug 字段将防止有人在网页上迭代的问题，并使 URL 对人们更清楚。

这个.com/object/10/ford-munstang-2010比.com/object/c30204225d8311e185c3002219f52617更清晰

【讨论】：

这是最好的例子：http://stackoverflow.com/questions/9400920/django-url-design-best-practices-for-identify-one-object 这里他们使用/AUTOINCREMENT_ID/SLUG_FIELD
此外，我们可以通过编辑数据库序列（在 PostgreSQL 的情况下）来解决迭代问题，例如将“增量”值设置为 2 o 3。这样我们生成一个序列中间有“洞”，避免重复。如果我们不希望该用户意识到我们拥有的内容数量，我们可以从一个随机的大数开始序列并从它开始计数。所以，这样我们就解决了所有的问题！这是 PostgreSQL 中序列版的链接：http://www.postgresql.org/docs/8.1/static/sql-altersequence.html
你试过访问stackoverflow.com/questions/9400920/some-incorrect-slug-here吗？他们将您重定向到以下页面（使用正确的 slug）：stackoverflow.com/questions/9400920/…。因此，我将使用id 来识别资源，并使用slug 来制作用户友好的网址;)
@Oscar Mederos 如果有任何错误的 slug（如上面的 some-incorrect-slug）当且仅当 id 部分是好的时才能恢复，如果这些是自动递增的，slug 如何阻止对 id 的迭代?

【解决方案2】：

ID 并不是严格意义上的“可迭代”。事物会被删除、添加回来等。随着时间的推移，很少有从 1 到 1000 的 ID 直线增长。从安全的角度来看，这并不重要。如果出于某种原因需要保护视图，您可以使用登录名并仅向每个用户显示允许每个用户查看的内容。

每种方法都有优点和缺点，但我发现 slug 是总体上最好的选择。它们是描述性的，它们可以帮助用户一目了然地知道那里的位置，使他们能够在单击 URL 时知道他们要去哪里。并且，可以通过以下方式减轻缺点（如果 slug 更改为 404）1）不要更改 slug，永远 2）当 slug 出于某种原因确实需要更改时设置适当的重定向。 Django 甚至内置了一个重定向框架，使这变得更加容易。

结合一个id 和一个蛞蝓的想法在我坐的地方简直太疯狂了。您仍然依赖 id 或 URL 的 slug 部分，因此它本质上与仅使用一个或另一个没有什么不同。或者，您同时依赖这两种方法，使您的问题更加复杂，并引入额外的故障点。两者同时使用并没有带来任何有意义的好处，而且似乎只不过是一种让人头疼的好方法。

【讨论】：

【解决方案3】：

没有人谈论 UUID 字段 (django model field reference page)，它可以很好地实现“哈希 id”。我想你可以有一个像这样的网址：

.com/object/UUID/slug

如果订单不相关，它会阻止在 URL 中显示订单。

其他选择可能是：

.com/object/yyyy-mm-dd/ID/slug
.com/object/kind/ID/slug

取决于您希望在 url 中包含的相关信息

【讨论】：