对于成功的用例，发布/重定向/获取 (PRG) 工作流程非常简单：只需将（客户端）重定向到所需页面。但是，如果在服务器端验证过程中遇到错误，并且我们希望在再次显示输入页面时保留输入，该怎么办？
据我所知，有两种方法：简单地在表单 POST 提交后重新渲染输入页面（即没有重定向）在错误期间（因此忽略 PRG 模式）；或者，重定向到输入页面，并将先前的输入存储在稍后可以在渲染期间检索的位置（例如会话）。两者都有缺点：首先，我们遇到了 PRG 模式帮助我们避免的问题（例如可收藏、重复提交）；第二种方法会导致 GET 不一致（第一个 GET 会找到存储的输入，随后的 GET 可能不会）。除了这里提到的还有其他选择吗？我希望社区就如何最好地处理此案提供意见。
【问题讨论】：
我通常按照您描述的第一种方式进行 - 仅在成功提交的情况下重定向。很难看到为包含无效数据的表单添加书签的真实用例；另一方面，为确认页面添加书签通常是有意义的（在成功提交之后）。
【讨论】：
如果用于填写表单的 URL 是表单发布到的 URL，我认为没有问题。如果输入有效，则重定向和 GET。如果无效，重新显示填写的表格。这样，交互看起来像：
GET /your-url => blank form
POST /your-url (success) => Redirect => GET /success-url
POST /your-url (failure) => filled-in form
【讨论】：
提到的书签问题影响了这两种方法，你不能真正为依赖于服务器上保存的一些临时数据的东西添加书签。
如果您确保验证失败时不保存任何数据（即每次数据失败的提交都是幂等请求），那么双重提交并不是真正的问题。
所以 PRG 只在成功时是一种非常干净的方法。
【讨论】：
就像其他答案所说，仅在成功的服务器端验证上使用 Post/Redirect/Get 模式。当表单无效时，只需直接响应响应，并带有错误消息。
为了可用性，您应该确保客户端验证非常好，这无论如何都是个好主意，因为用户喜欢即时反馈。使用Javascript，或者new HTML5 form features，比如required属性或者maxlength属性或者type="email"属性等等。
当然，您仍然应该进行服务器端验证，以确保安全和优雅降级。
【讨论】：
如果您使用的是 ASP.NET MVC，那么还有另一种方法可用于 Post -> 失败情况。本文第 13 条对此进行了介绍：ASP.NET MVC Best Practices (Part 1)。
如果您实施该方法，那么您可以始终在帖子之后重定向，即使帖子导致失败。
【讨论】：