`update` 的“Rails 方式”是否存在根本缺陷？答案

【问题标题】：Is the "Rails Way" for `update` fundamentally flawed?`update` 的“Rails 方式”是否存在根本缺陷？
【发布时间】：2012-03-06 01:17:41
【问题描述】：

我故意以煽动性的方式问这个问题，因为我担心我错过了什么。

处理模型更新的 Rails 方式如下：

class UsersController < ApplicationController
  ...
  def update
    @current_user = load_user
    if @current_user.update_attributes params[:user]
      redirect_to success_path
    else
      render :edit
    end
  end
end

这一切都很好，只是当表单提交不正确时您最终会访问一个奇怪的 URL：

编辑用户

你发现自己在路上：

users/:user_id/edit

提交未验证的修改后

即您将需要修复表单中的输入并重新提交：

users/:user_id

提交验证后的编辑

success_path

你为什么要因为表单有错误而使用不同的 URL？

问题...

您正在做同样的事情，但您现在位于不同的 URL。这有点奇怪。

坦率地说，这感觉不对。您使用的表单尚未正确验证，因此已重新加载。你应该还在/users/:user_id/edit。如果你做过 JS 验证，你会的。

此外，如果您的导航中有任何“当前选择”的逻辑，那么您实际上在视觉上处于错误的位置，因为正确的导航项不再突出显示 - 看起来您在用户个人资料中页面。

【问题讨论】：

争论语言的细节不合适
@KevinDTimm 你能解释一下你的意思吗？这是关于框架的编程问题，而不是语言问题
你在争论 RoR 的细节 - 为什么你应该在不同的 URL 上仅仅因为表单有错误？ - 将被定义为关于语言的设计决策，而不是关于如何在该语言中做某事的讨论。方式已经定义，你不同意 - 你自己这么说的。
好的，有道理。我已经更新了问题，更具体地说明了我实际需要知道的内容

标签： ruby-on-rails routing crud

【解决方案1】：

你为什么要在不同的 URL 上仅仅因为表单有错误吗？

因为你第一次去的时候：

users/:user_id/edit

...您正在请求 GET。

然后你发布到：

users/:user_id

因此，通过发送表单帖子，您请求了不同的资源路由，并且根据定义具有不同的 URL。

框架并不关心在处理您的请求时在后台发生了什么 - 它只知道这是一个 POST（按照惯例，它不一定像 GET 那样具有幂等性）

【讨论】：

感谢您的回答。我确实理解为什么 URL 发生了变化的机制，但是我的问题实际上是不同的。虽然我没有很好地沟通，但我已经更新了问题以反映真正的问题
您帖子中的唯一问题是“为什么要...？”。正如我所指出的，框架不知道 POST 中出现了错误，并且您已经重新渲染了编辑视图。关于您的“正确导航项目评论”；也许您的导航如何突出显示的过程不应该被硬编码为 URL 所说的内容，而是在 URL 路由到的控制器操作中的某些确定？ ;-)
@Pavling 我只是想知道你称谁为“框架”。引用：“框架不知道引发了错误”。那么谁在提出错误呢？在更具建设性的说明中，看起来 OP 理解它是如何工作的，问题是它为什么这样设计？ update 方法可以例如else redirect_to_failure_path 可以是任何东西（返回 id/edit 或 id/edit_please_correct_errors）。当然，这会带来其他问题，但这就是重点：哪些问题？

【解决方案2】：

其实不是“Rails 方式”，而是“REST 方式”。维基百科：Representational state transfer

如果您遵守规则，您将免费获得符合 REST 的网络服务。据我了解，路径“resource/id/edit”特定于 html 文档。 Web 服务客户端不需要编辑表单。

所以这些家伙试图保持一致。如果您不需要网络服务兼容性，当然可以更改路由。

【讨论】：

公平点。我并没有真正很好地传达我最初的问题，因此对其进行了更新以使其更有意义