您使用什么标准来决定是否嵌套资源？
过去，我选择在资源上的索引操作没有意义的情况下进行嵌套，而不将范围限定为关联资源（父级）。
即使在我写下上述标准时，我也意识到它充其量是模棱两可的。
一位同事表示：
嵌套资源，因为它在 url 结构中直观地捕获关联模型的关系......并且它可以轻松修改 url 以返回到帖子。如果我看到 /posts/123/offers/555 - 我知道我可以去 /posts/123 看到我的帖子。就好像我刚刚看到/offers/555 一样，除了手动浏览该站点之外，我没有办法返回帖子。
对我来说，用户对 url 的操作应该与应用程序的架构无关，并且违背了我理解的普遍持有的原则，即尽可能避免嵌套资源。此外，这个论点似乎支持多层次的嵌套，这也是我读过的几乎每一篇文章都反对的。
你有什么经验吗？
正如您首先提到的那样，我嵌套了路线，如果没有前者，路线中的后面的东西就没有意义。博客上的评论将嵌套在下面resources articles，因为尽管您可能希望在其自己的页面上显示单独的评论（谁知道为什么......），但评论属于一篇文章。
这也有控制器实现。如果您知道该文章，则可以找到该文章范围内的特定评论。这使得查询更有效。
此外，您的同事是正确的，您必须处理弄乱您的路线的用户，尽管他的理由是错误的。这不是为了他们的方便，而是为了他们的安全。
让我们以一个带有用户和订单的类似亚马逊的应用程序为例。如果我在，users/5/orders/2那么我会想“嘿！我可以将那个 5 更改为 4，然后查看其他人的订单！” 如果您不限定订单，那么用于授权用户查看的控制器级逻辑将orders/2变得更加棘手。对用户的范围限定允许current_user.orders.find(params[:id])在订单控制器中。可以根据身份验证找到当前用户，因此他们不能只是交换 URL 中的 id 并成为其他人。