假设我们有一个公司模型，它有很多员工和很多项目
如果我们想展示这些项目，我们会去
"/company/1/projects/index"
如果我们要编辑 1 个项目，我们将转到
"/company/1/projects/1/edit"
如果我们想在同一个网页上同时编辑所有项目怎么办？
我们可以转到“/company/1/edit”并为所有项目放置一个嵌套表单
但是，如果我们也需要一个不同的网页来同时编辑所有员工呢？
我们不能再使用“/company/1/edit”了..
现在我们执行“/company/1/projects/multiedit”、“/company/1/projects/multupdate”- 但正如您所见，这不是休息。
我们如何才能轻松地对此进行建模？
【问题讨论】：
标签： ruby-on-rails rest
你如何组织你的领域模型不应该是对 GUI 设计的主要影响，反之亦然。
如果我们想在同一个网页上一次编辑所有项目怎么办？
那么您可能应该为每个提供小部件并按顺序发布每个更新。您可以使用 AJAX 为最终用户提供良好的体验
现在我们执行“/company/1/projects/multiedit”、“/company/1/projects/multupdate”- 但正如您所见，这不是休息。
这很好，除非您需要 RESTful - 是吗？您的应用程序是供外部使用还是内部业务流程？
除了资源组织之外，REST 还有很多其他功能——无论是嵌套的还是其他的。您还应该关注资源表示的导航。
如果你真的觉得你需要 RESTful，并且如果你相信（正如你在下面的评论中提到的）所有项目和员工的状态需要自动更新，那么你应该
1。引入新的容器资源“Employees”和“Projects”来模拟公司与一组“员工”之间以及公司与一组“项目”之间的关联。
2。为了响应关于公司的 GET，您必须包含员工和项目资源的 URI（即总共两个 URI）。
3。作为对员工或项目的 GET 的响应，您应该返回所有底层资源的状态或每个资源的 URI，以便确定它们的状态。
4。更新员工时，您必须重新发送基础资源的所有状态（大概在一个巨大的 中）。新状态完全取代旧状态，
最后一步的开销很大——您应该重新考虑它是“全有或全无更新”的约束。请记住，这与 REST 无关 - 您所做的是向服务接口公开业务逻辑中的不变量。
1。尽我所能从表示层中删除该不变量
2。以非嵌套的方式对资源进行建模——它更灵活，REST 对 URI 没什么可说的，除了每个资源都应该有一个
3。引入员工和项目资源来模拟公司与员工和项目之间的关联
4。让公司代表返回项目和员工的 URI（再次两个）。
5。让每个员工和项目代表都包含到相关公司
6。设计 UI，以便它可以显示公司的项目/员工列表，并允许每个项目/员工单独更新
7。将所有 POST 批处理在一起，并通过 AJAX 在一个通用按钮上发送它们
值得一看的是 Ryan Bates 就嵌套资源制作的优秀截屏视频，但不要忘记嵌套资源不是 REST 的核心部分——引用 Roy Fielding 的话
重要的是每个重要资源都有一个 URI，其中允许使用 GET 获取该资源的表示。
说得够多了——祝你好运！ 克里斯
【讨论】：
【讨论】：
/company/1/edit?what=employees 或 '/company/1/edit?what=projects` 并将表单引用到 what 变量
/company/1/edit_employees 和 /company/1/edit_projects 会不会更好更直接地实现（只是几个路由和操作，没有条件代码来检查参数值）？
/company/1/employees/edit 和 /company/1/projects/edit 但前提是您不需要成员操作进行编辑 (project/1/edit) 否则 /company/1/edit_employees 可以
我认为您现在的做法实际上非常好。发明人工资源只是为了适应基本的 REST URL 方案对我来说似乎不合适。此外，Rails 具有集合和成员路由，正是为了添加额外的操作，所以您所做的事情符合 Rails 的理念。
对我来说，定义资源和操作类似于设计类。有时您添加了一些方法并意识到如果您将类分为两个设计会更好，但有时该类只需要具有所有这些方法。
除了应该处理多重编辑和多重更新的公司和项目之外，您是否有真正的资源？我想不是。但话又说回来，就像上课一样，有时这是一个见仁见智的问题。
【讨论】：