URL结构的最佳实践/标准

Question

我的建筑，项目站点，每个项目有一个页面，例如：

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

每个项目可以有多个子（和分分，分子分页），例如一本书可以有一个blurb，一部电影可以有一个画廊，一个游戏也可以有一个画廊。

我的问题是，围绕与物品相关的页面构建网址时是否存在任何标准或最佳做法？例如：

website.com/film/456/gallery 

凡亚页面出现后的项目，或：

website.com/film/gallery/456/ 

处的项目是URL的最后一部分。

没有人有任何关于的信息为什么哪种方法最好或者是否存在任何Web标准？这似乎是一个明显的事情，但我很难决定，我可以考虑每种方法的优点和缺点 - 虽然我倾向于前一种选择，因为这意味着以下用户路径将匹配URL：

load 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）

现在，如果一本书有blurb和blurb是唯一只对特定的书那么你将添加以下URL：

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

你可以做电影和画廊一样，提供每家画廊属于一个单电影。但是，如果画廊存在多部影片，那么您将使/galleries成为顶级网址。从电影导航到画廊仍然没问题。你不会有结构化的网址。你会得到，而不是通过GET含薄膜456画面中的所有画廊

• website.com/galleries?film=456

一般的规则是，如果你拥有的子资源的所有权关系您可以使用结构化网址，但是如果顶级项目之间的关系较松，查询参数就可以。不要陷入RESTful URL没有查询参数的常见误解。他们是这样。 :)

现在终于，直接回答你的问题：website.com/films/galleries/456是不是一个很好的网址恕我直言，因为`website.com/films/galleries/是不是很有用。事实上，我认为这相当难看。这意味着什么？所有画廊？如果是这样，它应该是website.com/galleries。

再次，我不认为这是标准化的任何地方，但它感觉非常常见和传统。