URL 结构最佳实践/标准

Question

我正在构建一个包含项目的网站，每个项目都有一个页面，例如:

website.com/book/123
website.com/film/456
website.com/game/789

每个项目都可以有多个子(和子子，子子子)页面，例如，一本书可以有一个简介，一部电影可以有一个画廊，一个游戏也可以有一个画廊。

我的问题是，在构建与项目关联的页面的 URL 方面是否存在任何类型的标准或最佳实践？例如:

website.com/film/456/gallery

子页面在项目之后的位置，或者:

website.com/film/gallery/456/

项目是 URL 的最后一部分。

有没有人知道为什么哪种方法最好，或者是否存在任何网络标准？这似乎是一件显而易见的事情，但我正在努力决定，我可以考虑每种方法的优缺点——尽管我倾向于前一个选项，因为这意味着以下用户路径将匹配网址:

加载 website.com -> 单击“电影”(website.com/films)-> 单击“电影”(website.com/film/123) -> 单击图库 (website.com/film/123/gallery )

但它似乎有些……不对劲，也许不一致。

Answer 1

您是正确的，以前的 URL “更好”并且部署更广泛。我认为您不会在任何标准 中找到此文件；它更像是一个约定。大多数涉及 REST 的文章和书籍都是这样做的。

如您所说，原因是URL中的路径组件与资源和子资源的结构相匹配。特别是，以下所有内容都应该是有效的 URL:

• website.com/
• website.com/books
• website.com/books/123

请特别注意，它是 books/123，不是 book/123，就像您拥有的那样。我见过单数形式，但恕我直言，复数形式更好。

对于 URL /books

• GET 获取所有书籍，但您可以使用查询参数限制书籍，例如/books?author=alice
• POST 添加一本新书(使用服务器生成的 ID)。

对于 URL /books/123

• GET 得到那本书
• PUT 替换具有该 ID 的图书(或添加具有该客户端生成的 ID 的图书)

现在，如果一本书有简介，并且简介仅对特定书籍是唯一的，那么您将添加以下 URL:

• website.com/books/123/blurbs
• website.com/books/123/blurbs/72

您可以为电影和画廊做同样的事情，前提是每个画廊都属于一部电影。但是，如果画廊存在多部电影，那么您可以将 /galleries 设置为顶级 URL。从电影导航到画廊仍然没问题。你不会有一个结构化的 URL。相反，您将通过 GET 获取包含电影 456 中图片的所有画廊

• website.com/galleries?film=456

一般规则是，如果您有子资源的所有权关系，您可以使用结构化 url，但如果顶级项目之间的关系较松散，查询参数就可以了。不要误以为 RESTful URL 没有查询参数；他们是这样。 :)

现在终于可以直接回答您的问题了:website.com/films/galleries/456 恕我直言，这不是一个好的 URL，因为 `website.com/films/galleries/ 不是很有用。其实我觉得挺丑的。这意味着什么？所有画廊？如果是这样，它应该是 website.com/galleries。

同样，我认为这在任何地方都没有标准化，但感觉非常普遍和传统。