我正在构建一个包含项目的网站，每个项目都有一个页面，例如：
website.com/book/123
website.com/film/456
website.com/game/789
每个项目可以有多个子（和子子、子子子）页面，例如一本书可以有一个简介，一部电影可以有一个画廊，游戏也可以有一个画廊。
我的问题是，围绕为与项目关联的页面构建 URL 是否存在任何类型的标准或最佳实践？例如：
website.com/film/456/gallery
子页面在项目之后的位置，或：
website.com/film/gallery/456/
其中 item 是 URL 的最后一部分。
有没有人知道为什么哪种方法最好，或者是否存在任何网络标准？这似乎是一件显而易见的事情，但我正在努力做出决定，我可以考虑每种方法的优缺点——尽管我倾向于前一个选项，因为这意味着以下用户路径将与 URL 匹配：
加载 website.com -> 单击“电影”（website.com/films）-> 单击“电影”（website.com/film/123）-> 单击画廊（website.com/film/123/gallery）
但关于它的一些东西似乎......关闭，可能不一致。
您是正确的，前一个 URL“更好”并且部署更广泛。我认为您不会在任何标准中发现这一点；它更像是一种约定。大多数涉及 REST 的文章和书籍都是这样做的。
这样做的原因是，如您所说，URL 中的路径组件与资源和子资源的结构相匹配。特别是，以下所有内容都应该是有效的 URL：
特别要注意，它是books/123，而不是 book/123像您那样。我见过单数，但恕我直言，复数更好。
对于网址 /books
/books?author=alice对于网址 /books/123
现在，如果一本书有简介，并且简介仅对特定书籍是唯一的，那么您将添加以下 URL：
你可以对电影和画廊做同样的事情，前提是每个画廊都属于一部电影。但是，如果有多个电影的画廊，那么您将制作/galleries一个顶级 URL。从电影导航到画廊仍然可以。你不会有一个结构化的 URL。相反，您将通过 GET 获取包含来自电影 456 的图片的所有画廊
一般规则是，如果您对子资源有所有权关系，则可以使用结构化 url，但如果顶级项目之间的关系较松散，则查询参数就可以了。不要陷入 RESTful URL 没有查询参数的常见误解；他们是这样。:)
现在终于，直接回答你的问题：website.com/films/galleries/456恕我直言，这不是一个好的 URL，因为`website.com/films/galleries/它不是很有用。其实我觉得还是挺丑的。这意味着什么？所有画廊？如果是这样，应该是website.com/galleries。
同样，我不认为这在任何地方都是标准化的，但感觉非常普遍和传统。