3

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

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)

但它的某些东西似乎......关闭，可能不一致。

4

1 回答 1

5

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

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

  • 网站.com/
  • website.com/books
  • website.com/books/123

特别要注意的是，它books/123不是你 book/123所拥有的。我见过单数，但恕我直言，复数更好。

对于网址/books

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

对于网址/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。

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

于 2011-10-15T03:32:36.890 回答