URL 结构最佳实践/标准
我正在构建一个包含项目的网站，每个项目都有一个页面，例如：
website.com/book/123
website.com/film/456
website.com/game/789
每个项目可以有多个子（和子子，子子子）页面，例如一本书可以有一个简介，一个电影可以有画廊，游戏也可以有画廊。
我的问题是，是否存在围绕构建与项目关联的页面的 URL 的任何类型的标准或最佳实践？例如：
website.com/film/456/gallery
子页面位于项目之后，或者：
website.com/film/gallery/456/
项目是 URL 的最后一部分。
有谁知道为什么哪种方法最好或者是否存在任何网络标准？这似乎是一件明显的事情，但我正在努力做出决定，我可以想到每种方法的优缺点 - 尽管我倾向于前一种选择，因为这意味着以下用户路径将匹配URL：
加载 website.com ->点击“电影”(website.com/films)->点击“一部电影”(website.com/film/123)->单击画廊（website.com/film/123/gallery），
但有关它的某些内容似乎...关闭，也许不一致。
I'm building a site that has items, with each item having a page, for example:
website.com/book/123
website.com/film/456
website.com/game/789
Each item can have multiple sub (and sub-sub, sub-sub-sub) pages, for example a book could have a blurb, a film could have a gallery and a game could also have a gallery.
My question is, does any sort of standard or best practice exist around structuring the URLs for pages associated with an item? For example:
website.com/film/456/gallery
Where the sub page comes after the item, or:
website.com/film/gallery/456/
where the item is the very last part of the URL.
Does anyone have any information on why which approach is best or if any web standard exists? It seems an obvious thing but I'm struggling to decide, I can think of pros and cons for each approach -- although I'm leaning towards the former option because it means the following user path would match the URL:
load website.com -> click "films" (website.com/films)-> click "a film" (website.com/film/123) -> click gallery (website.com/film/123/gallery)
but something about it seems... off, inconsistent maybe.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您认为前一个 URL“更好”并且部署更广泛，这是正确的。我认为您不会在任何标准中找到此记录；这更像是一个约定。大多数涉及 REST 的文章和书籍都是这样做的。
正如您所说，原因是 URL 中的路径组件与资源和子资源的结构相匹配。特别是，以下所有内容都应该是有效的 URL：
特别要注意的是，它是
books/123，不是book/123就像你一样。我见过单数，但恕我直言，复数更好。对于 URL
/books，/books?author=alice对于 URL
/books/123，现在，如果一本书有简介，并且简介是仅针对特定书籍，那么您将添加以下 URL：
您可以执行以下操作：电影和画廊也是如此，前提是每个画廊都属于一部电影。但是，如果存在多部电影的画廊，那么您可以将
/galleries设为顶级 URL。从电影导航到画廊仍然没问题。你不会有一个结构化的 URL。相反，您可以通过 GET 访问来获取包含电影 456 中的图片的所有画廊一般规则是，如果您对子资源有所有权关系，则可以使用结构化 url，但如果存在更宽松的情况顶级项目之间的关系，查询参数都很好。不要陷入 RESTful URL 没有查询参数的常见误解；他们确实这么做了。 :)
现在最后，直接回答您的问题：
website.com/films/galleries/456恕我直言，这不是一个好的网址，因为`website.com/films/galleries/不是很有用。事实上我认为它相当丑陋。这意味着什么？所有画廊？如果是这样，它应该是website.com/galleries。我再次认为这在任何地方都没有标准化，但感觉非常普遍和传统。
You are correct that the former URL is "better" and is more widely deployed. I don't think you would find this documented in any standard; it is rather more of a convention. Most articles and books covering REST do it that way.
The reason for this is, as you say, that the path components in the URL match the structure of resources and sub-resources. In particular, all of the following should be valid URLs:
In particular, note that it is
books/123, notbook/123like you have. I have seen the singular but IMHO the plural is better.For the URL
/books/books?author=aliceFor the URL
/books/123Now if a book has blurbs and the blurbs are unique only to a particular book then you will add the following URLs:
You can do the same for films and galleries, provided each gallery belonged to a single film. But if galleries existed for multiple films, then you would make
/galleriesa top-level URL. Navigating from a film to a gallery would still be fine. You wouldn't have a structured URL. You would instead get all galleries containing pictures from film 456 via a GET toThe general rule is that if you have an ownership relation for the subresources you can use structured urls, but if there is a looser relationship among top-level items, query parameters are fine. Don't fall into the common misconception that RESTful URLs don't have query parameters; they do. :)
Now finally, to directly answer your question:
website.com/films/galleries/456is not a good URL IMHO because`website.com/films/galleries/is not very useful. In fact I think it is rather ugly. What would it mean? All galleries? If so, it should bewebsite.com/galleries.Again I don't think this is standardized anywhere, but it feels very common and conventional.