我正在构建一个包含项目的网站，每个项目都有一个页面，例如：
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 - ＆gt;点击“电影”（website.com/films)->点击“电影”（website.com/film/123） - ＆gt;点击图库（website.com/film/123/gallery）
但有些事情似乎......关闭，可能不一致。
答案 0 :(得分：4)
您是正确的，以前的URL是“更好”，并且更广泛地部署。我认为您不会在任何标准中找到此文档;它更像是一种惯例。大多数关于REST的文章和书都是这样做的。
正如您所说，原因是URL中的路径组件与资源和子资源的结构相匹配。特别是，以下所有内容都应该是有效的URL：
请特别注意，您有books/123，不 book/123。我见过单数，但恕我直言复数更好。
对于网址/books
/books?author=alice 对于网址/books/123
现在，如果一本书有模糊，并且模糊仅对某本书是唯一的，那么您将添加以下网址：
如果每个画廊属于一部电影，你可以为电影和画廊做同样的事情。但是，如果多个电影的画廊存在，那么您可以将/galleries设为顶级网址。从电影导航到画廊仍然没问题。你没有结构化的URL。你可以通过GET将所有包含电影456的图片的画廊改为
一般规则是，如果您拥有子资源的所有权关系，则可以使用结构化网址，但如果顶级项目之间存在较松散的关系，则查询参数就可以了。不要陷入RESTful URL没有查询参数的常见误解;他们是这样。 ：）
现在最后，直接回答你的问题：website.com/films/galleries/456不是一个好的网址恕我直言，因为`website.com/films/galleries/不是很有用。事实上，我认为这是相当丑陋的。这是什么意思？所有画廊？如果是，则应为website.com/galleries。
我不认为这在任何地方都是标准化的，但感觉非常普遍和传统。