Django - URL 设计和识别一个对象的最佳实践
我实际上在 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，而不是在“更新”操作中保存。但现在，蛞蝓可以代表旧的或不正确的东西。
所有选项都有优点和缺点。可能使用它们的某些组合可以解决一些问题。 你对此有何看法？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为最好的选择是：
为什么？
第一个原因：AUTOINCRMENT_ID 很容易让用户识别对象。例如，在电子商务网站中，如果用户想要多次访问该页面（因为他不确定是否购买该产品），他将识别该 URL。
第二个原因： slug 字段可以防止有人迭代网页的问题，并使 URL 对人们来说更加清晰。
这个
.com/object/10/ford-munstang-2010比.com/object/c30204225d8311e185c3002219f52617更清晰I think the best option is this:
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-2010is clearer than.com/object/c30204225d8311e185c3002219f52617ID 并不是严格意义上的“可迭代”。内容会被删除、添加回来等等。随着时间的推移，ID 很少会从 1 到 1000 呈直线增长。从安全角度来看，这并不重要。如果出于某种原因需要保护视图，您可以使用登录名并仅向每个用户显示允许每个用户查看的内容。
每种方法都有优点和缺点，但我发现总体而言，蛞蝓是最好的选择。它们是描述性的，可以帮助用户一目了然地知道那里在哪里，让他们在点击 URL 时就能知道他们要去哪里。而且，可以通过以下方式缓解缺点（如果 slugs 发生更改，则为 404s）：1）永远不要更改 slugs；2）当 slugs 因某种原因确实需要更改时，设置适当的重定向。 Django 甚至内置了一个重定向框架，使这一切变得更加容易。
从我现在的角度来看，将 id 和 slug 结合起来的想法简直太疯狂了。您仍然依赖 URL 的 id 或 slug 部分，因此本质上与单独使用其中之一没有什么不同。或者，您同时依赖两者，从而使您的问题变得更加复杂，并引入其他故障点。使用两者根本不会带来任何有意义的好处，而且似乎只不过是带来头痛的好方法。
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.
没有人谈论 UUID 字段（django 模型字段参考页面) 这可以很好地实现“hash id”。我认为你可以有一个像这样的网址：
如果订单不相关，它会阻止在网址中显示订单。
其他替代方案可能是：
取决于您希望在网址中包含的相关信息
Nobody talked about the UUID field (django model field reference page) which can be a good implementation of the "hash id". I think you can have an url like:
It prevents from showing an order in the URL if this order is not relevant.
Other alternatives could be:
depending of the relevant information you want to have in the url