好的，这是一个示例场景。学生资源resources :students，学生拥有并属于许多馆藏：resources :clubs，resources :majors等。
所以我们可以轻松地设置路线......
resources :clubs do
resources :students
end
resources :majors do
resources :students
end
resources :students do
resources :clubs
resources :majors
end
为我们生成了一堆标准的RESTful路由
所以这是我的问题。使用REST语义，如何删除学生的专业？
浏览专业/majors/:major_id/students/:id下的学生会向特定专业的“收藏”中的学生展示。但是删除：id的路径指向StudentsController#destroy，这将完全删除学生。哎呦！所以也许我们走另一条路，并在/students/:student_id/majors/:id的资源上执行DELETE，现在已经在这所学校不再提供UnderwaterBasketweaving ...哎呀！
现在已经授予，我们可以设置ClubsController，MajorsController或StudentsController的destroy方法来查找club_id，major_id或student_id，但是我们可以说我们也想要添加Fraternities和GraduatingClasses等。每个类都会开始由巨大的开关条件组成，以查看存在什么样的参数...然后找到顶级资源的集合并删除底部资源，反之亦然。 模型本身应决定是否删除自己，如果他们没有更多的关联记录...'Destroy'在该资源上变得真的是一个误称......
有更简单的方法吗？甚至像make_resourceful或resource_controller这样的流行的宁静轨道插件也会在从Joe's Majors中删除它时将其吹走UnderwaterBasketweaving，或者在将他从主要的UnderwaterBasketweaving中删除时完全删除JohnDoe。似乎有可能通过查看关联来理解语义的预期效果以及“破坏”应该做什么。
然后再次，我看到这一切都错了吗？是不是UnderwaterBasketweaving - ＆gt; Joe但UnderwaterBasketweaving + Joe作为单一资源而我们正在删除的内容真的不是Joe，也不是UnderwaterBasketweaving，而是代表组合的资源？然而，当控制器是学生和专业时，这并不容易，这实际上代表同名资源（MVC实际上已成为RV ......在“约定”方法中而不是开发可能与之无关的控制器模型名称或到达它的路径所以你要删除一个专业或学生;选择你的毒药...
如何避免在关联资源的无限图表中管理条件，其中删除实际上不是意图当删除需要在集合的上下文中而不是与其奇点相关时...？
... major.student.delete ...“学生”ActiveRecord对象是否有办法知道在“主要”AR对象开头的方法链中发送了“删除”消息？
答案 0 :(得分：2)
标准的RESTful aproach是使用has_many :through并为关联资源生成一个cotroller。命名关联资源总是很困难，但我会尝试这个例子。
resources :majors do
resources :studies
resources :students
end
resources :students do
resources :studies
resources :majors
end
模型当然是：
class Major < ActiverRecord::Base
has_many :studies
has_many :students, :through => :studies
end
等。 （评论如果你想让我详细说明）
然后，对于学生，你不会删除它与@student.major相关联的@student.studies.where :major => @major。