friendly-url - 友好的 URL 应该在开头还是结尾有 ID？

Question

所以我计划为我的网站提供友好的 URL，其中每个页面都有自己的 ID。所以我发现了人们这样做的两种常见方式:

http://www.example.com/page/123/slug-for-the-page
http://www.example.com/page/slug-for-the-page/123

哪一个是首选？支持和反对的论据是什么？我发现在输入 URL 时，第二种形式更容易，因为浏览器更容易从历史记录或书签中自动完成。但对我来说，最后有ID真的很奇怪。

对于与当前不匹配的任何 slug，我将使用重定向到规范 URL。但是，当 slug 是唯一的时，人们是否也会从具有 slug 但没有 ID 的 URL 进行重定向？例如，重定向 http://www.example.com/page/slug-for-the-page至 http://www.example.com/page/slug-for-the-page/123 .

Answer 1

先说一段历史:

这些 URL 的最初原因是人们希望他们的数据库仅按 ID 进行索引。通过 slug 进行索引(并强制执行唯一性)对于计算机和程序员来说都是额外的工作。 Rails 使这种风格流行起来 ( /page/1 )。

但是这种风格对搜索引擎来说是相当不透明的。所以人们在 ID ( /page/1-slug-for-page ) 之后添加了 slug 来帮助搜索引擎(和用户)。但是作为结尾的文本是无关紧要的——只有数字很重要。 slug 甚至可能不会存储在数据库中(有时它是自动生成的)，并且它没有被索引以节省空间。

Which one is preferred?

对于将 ID 放在 URL 中，任何一种样式都可以，但“数字然后 slug”样式更受欢迎。

I will use redirects to canonical URL for any slug which does not match the current one. But do people also do redirects from URL having slug, but no ID, when the slug is unique?

随便挑 ID或 slug并运行它。

1)如果你通过ID查找，你应该忽略slug(它们只适用于搜索引擎)。如果您有 ID，您可以轻松重定向到“真实”的 slug。 (更正任何被截断的 URL 等)

2) 如果您通过 slug 查找，您的 slug 需要是唯一的。 (大多数站点按日期范围以使其更容易)。一旦对 slug 进行数据库查找，就不清楚为什么甚至需要 URL 中的 ID。 (它们看起来很丑而且很随意，所以最好放弃它们。)你提议的是额外的工作(对你和计算机来说)，但我不确定它是否有用。

只有高流量站点需要担心索引大小/速度权衡对 slug 与 ID 的索引。即便如此，也可以通过一些技巧来最小化差异。 (即不要查找 slug，而是查找 slug MD5 的前 8 个字符。)