如何在 REST 中管理状态
我想这个问题听起来很熟悉，但我是另一个对 REST 感到困惑的程序员。
我有一个传统的 Web 应用程序，从 StateA 到 StateB 等等。 如果用户访问 StateB（的 URL），我想确保他之前访问过 StateA。 传统上，我使用会话状态来执行此操作。
由于 REST 中不允许会话状态，我该如何实现这一点？
I guess this question will sound familiar, but I am yet another programmer baffled by REST.
I have a traditional web application which goes from StateA to StateB and so on.
If the user goes to (URL of) StateB, I want to make sure that he has visited StateA before.
Traditionally, I do this using session state.
Since session state is not allowed in REST, how do I achieve this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对此有 2 个 REST 答案，具体取决于您具体想要做什么。
如果您确实尝试管理基于请求的状态（例如当用户正在通过多屏幕向导或其他一些基于导航的工作流程工作时），那么 REST 答案是状态应该与每个请求/响应（使用诸如隐藏文本字段、查询字符串或存储在表单中的 POST 数据之类的内容）。这是 Martin Fowler 的“客户端状态”设计模式的实现（在他的书企业应用程序架构模式中有详细介绍；请参阅此处供参考）。
另一方面，如果您尝试管理服务器上的某种新对象（例如购物车），那么 REST 答案是您实际上正在创建一个新实体，可以像其他任何实体一样访问该实体直接网址。是否将此新实体存储在数据库或应用程序内存中（如传统的 Session 对象）取决于您，但是，无论哪种方式，新对象都与服务器上的“状态”无关，而更多地与创建新对象有关供用户交互的实体。
There are 2 REST answers to this, depending on what specifically you are trying to do.
If you are truly trying to manage request-based state (such as when a user is working through a multi-screen wizard or some other navigation-based workflow), then the REST answer is that state should be sent back-and-forth with each request/response (using something like a hidden text field, a query string, or POST data stored in a form). This is an implementation of Martin Fowler's "Client State" design pattern (detailed in full in his book, Patterns of Enterprise Application Architecture; see here for a reference).
If you are, on the other hand, trying to manage some sort of new object on the server--such as a shopping cart--then the REST answer is that you are actually creating a new entity that can be accessed like any other by a direct URL. Whether or not you store this new entity in a database or in application memory (like a traditional Session object) is up to you, but, either way, the new object is less about "state" on the server and more about creating a new entity for the user to interact with.