处理由REST中的无效PUT / POST引起的UX混淆的最佳方法？

Question

我的堆栈是Rails，但问题实际上是与框架无关的

REST方法说明

要查看现有用户的编辑表单：

GET: users/:id/edit

为了更新现有用户：

PUT: users/:id

这对验证错误意味着什么

除非表单无法验证，否则这一切都是明智的。当表单未验证您最终使用的网址时，不是users/:id/edit网址，而是：

users/:id

这会导致两个问题。一个是导航，另一个是用户刷新表单时发生的情况：

一个全新的编辑表单：

同样的错误形式 - 虽然网址和导航表明我们的位置不同

视觉上该页面现在令人困惑，因为导航和网址表明用户不在编辑表单上，而是在resource#show页面上。

用户现在刷新表单时会看到什么 - 一个完全不同的页面

它还有其他含义。如果用户感到沮丧并且只是想重置表单，他们的本能将是刷新页面。如果他们这样做，虽然他们会在resource#show页面而不是resource#edit页面找到自己。

天真地，我们可能会将无效的提交重定向回resource#edit网址。如果我们这样做，虽然我们不会（默认情况下在Rails中）能够向他们显示他们刚刚提交的表单中的错误，因为这些错误存储在内存中。

可能的解决方案

据我所知，有两种方法可以解决这个问题：

1. 当PUT users/:id无法验证时：序列化user对象并将其存储在会话中。重定向到GET users/:id/edit，然后在下一页上反序列化对象以显示错误 - 感觉很乱
2. 更改路由，使PUT转到users/:id/edit而不是users/:id - 也会感到混乱。

问题

解决此问题的最合适方法是什么？我觉得序列化方法可能最有意义，但由于它不是Rails核心的一部分，我觉得我错过了一些东西。我知道我不是第一个解决这个问题的人，并且对别人的方法感兴趣

Answer 1

首先，这是开箱即用的rails应用程序中的典型行为。

如果有人提交了无效表单，那么刷新页面，应该发生什么？在您已经看到并且在典型的rails应用程序中，我们只是刷新并且（在更新记录的情况下）可能会将它们从用户体验中弹出。 IMO，没关系。刷新有时会破坏网络：）

当设计师想要更改“无效”页面的样式或者开发人员正在查看错误页面上的呈现错误时，通常会看到这种情况，他们修复代码或css然后刷新页面可能期望看到页面已修复，但他们可能会得到和错误相关/管道工不接受获取请求或他们被放回管道工#index页面。

简短回答通常这对大多数rails应用来说都不是什么大问题，并且这样做是为了让我们不必依赖于暂时存储他们的会话中的答案和错误，只是为了重定向回编辑页面，这一切都在一个请求和响应周期中完成。

如果您想改变行为，可以执行类似

的操作

 class PlumbersController
    def update 
       plumber = Plumber.find(params[:id]) 
       if plumber.update(params[:plumber])
          redirect_to(plumbers_path, :message => "successfully updated!")
       else 
         flash[:plumber_attributes] = params[:plumber]
         redirect_to plumber_edit
       end
    end
    def edit
       @plumber = Plumber.find(params[:id])  
       @plumber.assign_attributes(flash[:plumber]) if flash[:plumber.present?]
    end
  end

注意：此代码尚未经过测试。一般的想法是将管道工属性弹出到flash并重定向到管道工编辑URL。

也就是说，您所描述的行为是典型的，并且rails解决它的唯一方法是依赖会话（flash）来应用逻辑，它选择不开箱即用。