因此，使用Rails的REST资源路由，我们最终得到了与Controller操作协调的自动生成的路由（我将避免咆哮我如何复制模型两次，以及关系两次（作为模型然后as（通常）嵌套资源;以及两次动作（因为我在适用的情况下用onlys / excepts限制我的资源，然后只将那些动作编码到控制器中;所以我的控制器的公共方法实际上是我的行为......无论如何，我离题了）
对我来说变成一个主要的问题是，当验证停止保存并退出渲染时：new / render：edit但是此时，客户端的URI指向的不是...... / new或者...... /：id /编辑了。这似乎严重打破了REST范式;因为我们没有改变状态但我们已经转移了。也许这就是为什么我在非AJAX或WebService场景中接受RESTful练习这么长时间的原因，在这种情况下可以在不改变页面的情况下进行调用和处理。在真正的REST资源表示中，我们不应该指向资源/：id / edit，而只是从PUT动词推断。
在Rails的旧时代，我们将... / new form point重新设置为new，控制器条件如request.post？ 。如果验证因任何原因失败，可以不重定向到GET，但用户仍然在... / new，这是有道理的。他们可以一遍又一遍地重新加载，只要我们的控制器检查了POST与GET的新操作，它就会继续出错，或者重新加载空白表单。成功后，我们继续使用Get / Post / Get模式。
那么，普遍的共识是什么（我知道我可以破解POST / PUT数据进入闪存，但我更喜欢干净的东西）关于如何处理资源位置切换，并且失败，现在显示'新'基于URI（以及合并Rails'... / new || ... / edit范例）的形式应该是'show'或'index'？
（次要问题：如果练习真正的REST，我们应该如何/可以在POST或PUT之前获取有关资源的信息，因为没有架构的广播契约，如SOAP所说的那样。换句话说，为了避免诸如... / edit和... / new之类的“hacks”（如果在REST方法中列出URI中的其他动词，那么它肯定被认为是糟糕的形式... / show，.. ./delete等，因为URI中动词的存在会减少它作为资源而不是object.method对的方面。
答案 0 :(得分：0)
如果您确实希望URL保持不变，则可以始终实施客户端验证并禁用“创建”或“更新”按钮;这意味着您可以跳过if-else循环，如果保存仍然失败，则抛出错误。
如果查看默认的Rails XML路由，它通常甚至没有new和edit方法，但只返回带有生成错误的XML。这实际上与HTML相同，只是Rails正常处理它并允许用户立即重试。
当然，如果你真的想要摆脱/ new和/ edit'hacks'（就像你所说的那样），你可以在索引视图中包含一个'new'表单并包含编辑资源的功能在同一资源的展示视图上。
另一个改进是在create和update方法中在else上返回422（：unprocessable_entity）而不是200;这通常是为XML输出实现的，但大部分都不是针对HTML输出实现的。然后你至少会向客户表明它提供的输入无效。