如何在 REST 中管理状态答案

【问题标题】：How to manage state in REST如何在 REST 中管理状态
【发布时间】：2011-02-08 04:08:23
【问题描述】：

我想这个问题听起来很熟悉，但我是另一个对 REST 感到困惑的程序员。

我有一个从 StateA 到 StateB 的传统 Web 应用程序，依此类推。如果用户访问 StateB 的（URL），我想确保他之前访问过 StateA。传统上，我使用会话状态来执行此操作。

由于 REST 中不允许会话状态，我该如何实现？

【问题讨论】：

在课堂上使用@Stateful。

标签： rest session-state

【解决方案1】：

对此有 2 个 REST 答案，具体取决于您要做什么。

如果您确实在尝试管理基于请求的状态（例如，当用户通过多屏向导或其他基于导航的工作流程工作时），那么 REST 的答案是应该将状态发回 - 并且-forth 每个请求/响应（使用诸如隐藏文本字段、查询字符串或存储在表单中的 POST 数据之类的东西）。这是 Martin Fowler 的“客户端状态”设计模式的实现（在他的书企业应用程序架构的模式中有详细介绍；请参阅here for a reference）。

另一方面，如果您正在尝试管理服务器上的某种新对象（例如购物车），那么 REST 的答案是您实际上是在创建一个可以像这样访问的新实体任何其他的直接 URL。是否将此新实体存储在数据库或应用程序内存中（如传统的 Session 对象）取决于您，但是，无论哪种方式，新对象都不是关于服务器上的“状态”，而是更多关于创建新的供用户交互的实体。

【讨论】：

只有一点。如果您采用“服务器上的新对象”方法，则应将其视为一流资源并应具有标识 url。
自己尝试了解 REST...我很好奇：“头等舱”在这种情况下是一个技术术语吗？
@Darrel\ Miller 我认为教条式的 REST 还需要多页向导的 URL。启动向导将创建一个新资源，为每个页面创建一个新资源，每个页面的响应都包括一个“下一个”链接。您可以施加一个约束，即必须在“最终资源”之前创建所有“页面资源”；这可以通过1/2/3/submit 之类的 URL 隐式完成。这似乎有点傻，因为它只是使用 URL 重新创建会话状态。一个优点是如果 URL 是永久链接，会话就不会超时。您可以将其添加为书签以便稍后完成。
有趣的观点。 “状态”（要来回传输）和“资源”（要分配 URI）之间的边界在哪里？是关于“具体性”，比如“一堆导航信息是一种状态，但任何看起来更像实体、容器或对象的东西都是资源”？或者更多的是关于生命的时间？还是范围？
@ChristianGosch 似乎区分这两者的一件事（对我来说，无论如何）是会话持久性。也就是说，如果客户端失败（或注销），丢失什么是可以接受的？丢失的将处于应用程序状态。万一客户端失败（或注销），您想要保留的任何内容都必须存储在资源中。亚马逊的购物车就是一个例子。