让我们说我们有一个公司模型，有很多员工，有很多项目
如果我们要展示项目，我们将转到 “/公司/ 1 /项目/索引”
如果我们要编辑1个项目，我们将转到
“/公司/ 1 /项目/ 1 /编辑”
如果我们想在同一网页上同时编辑所有项目怎么办？ 我们可以转到“/ company / 1 / edit”并为所有项目添加嵌套表单
但是如果我们需要一个不同的网页来同时编辑所有员工呢？ 我们不能再使用“/ company / 1 / edit”了。
现在我们做“/ company / 1 / projects / multiedit”，“/ company / 1 / projects / multupdate” - 但正如你所看到的，它并没有休息。
我们如何能够安静地模拟这个？
答案 0 :(得分：3)
如何组织域模型不应该是GUI设计的主要影响因素，反之亦然。
如果我们想在同一网页上一次编辑所有项目怎么办？
然后你可能应该为每个提供小部件并按顺序POST每个更新。您可以使用AJAX为最终用户提供良好的体验
现在我们做“/ company / 1 / projects / multiedit”，“/ company / 1 / projects / multupdate” - 但正如你所看到的，它并没有休息。
除非你需要RESTful，否则这很好 - 你呢？您的申请是外部使用还是内部业务流程？
REST比组织资源还要多得多 - 嵌套或其他方式。您还应该关注资源表示的导航。
如果您真的觉得自己需要RESTful，并且如果您认为（正如您在下面的评论中提到的那样）所有项目和员工的状态需要自动更新，那么您应该
1。引入新的容器资源“员工”和“项目”来模拟公司与一组“员工”之间以及公司与一组“项目”之间的关联。
2。为响应公司的GET，您必须包含Employees和Projects资源的URI（即总共两个URI）。
3。为了响应员工或项目的GET，您应该返回所有底层资源的状态或每个的URI，以便确定其状态。
4。更新Employees时，您必须重新发送所有底层资源的状态（可能是一个巨大的）。新州完全取代旧州，
最后一步是很多开销 - 你应该重新考虑它的“全部或全部更新”的约束。请记住，这与REST无关 - 您所做的是将业务逻辑中的不变量暴露给服务接口。
1。尽我所能从表示层中删除该不变量
2。以非嵌套的方式对资源进行建模 - 它更灵活，REST对URI没什么可说的，除了每个资源都应该有一个
3。介绍员工和项目资源，以模拟公司与员工和项目之间的关联
4。让公司的代表返回项目和员工的URI（再次两个）。
5。让每个员工和项目代表包含一个相关公司
6。设计用户界面，以便它可以显示公司的项目/员工列表，并允许每个人单独更新
7。将所有POST一起批处理并通过AJAX在常用按钮上发送
值得一看的是Ryan Bates在嵌套资源上所做的优秀截屏，但不要忘记嵌套资源不是REST的核心部分 - 引用Roy Fielding
重要的是每个重要资源都有一个URI，其中允许使用GET获取该资源的表示。
够了 - 祝你好运！ 克里斯
答案 1 :(得分：0)
API：
http://apidock.com/rails/ActiveRecord/NestedAttributes/ClassMethods/accepts_nested_attributes_for
检查Rayan Bates Railscasts：
http://railscasts.com/episodes/197-nested-model-form-part-1
http://railscasts.com/episodes/197-nested-model-form-part-2
答案 2 :(得分：0)
我认为你现在这样做的方式实际上非常好。为了适应基本的REST URL方案而发明人工资源对我来说似乎不对。此外，Rails具有精确的集合和成员路径，以便添加额外的操作，因此您所做的是符合Rails理念。
对我来说，定义资源和操作类似于设计类。有时你会添加一些方法，并意识到如果你将类分成两部分，设计会更好，但有时候类只需要拥有所有这些方法。
除了应该处理multiedit和multiupdate的公司和项目之外，您是否拥有真正的资源？我想不是。但话说回来，就像课程一样，有时这是一个意见问题。