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