如果 REST 应用程序应该是无状态的，您如何管理会话? [英] If REST applications are supposed to be stateless, how do you manage sessions?
问题描述
我需要澄清一下.我一直在阅读有关 REST 和构建 RESTful 应用程序的信息.根据维基百科，REST 本身被定义为具象状态传输.因此，我无法理解每个人都在不断喷出的所有这些无状态的gobbledeygook.
来自维基百科:
<块引用>在任何特定时间，客户都可以在应用程序状态或静止".处于休息状态的客户端能够与其用户交互，但不创建负载并且不消耗每个客户端存储在服务器组或网络上.
他们只是说不要使用会话/应用程序级数据存储吗???
我知道 REST 的一个目标是使 URI 访问一致且可用，例如，不是将分页请求隐藏在帖子中，而是将请求的页码作为 GET URI 的一部分.我感觉合理.但似乎说每个客户端的数据(会话数据)都不应该存储在服务器端，这似乎有点过分了.
如果我有一个消息队列，并且我的用户想要阅读这些消息，但是当他阅读这些消息时，想要在他的会话期间阻止某些发件人的消息，该怎么办?将其存储在服务器端的某个位置并让服务器仅发送未被用户阻止的消息(或消息 ID)是否有意义?
每次请求新邮件列表时，我真的必须发送要阻止的整个邮件发件人列表吗?与我相关的消息列表一开始就不会/不应该是公开可用的资源..
再次，只是试图理解这一点.有人请澄清.
更新:
我发现了一个堆栈溢出问题，该问题的答案并没有让我完全明白:如何在 REST 中管理状态这表示重要的客户端状态应该在每个请求中都被传输...... Ugg ......似乎有很多开销......这是对的吗?
基本解释是:
<块引用>服务器上没有客户端会话状态.
无状态意味着服务器不会在服务器端存储任何关于客户端会话的状态.
客户端会话存储在客户端上.服务器无状态意味着每个服务器都可以随时为任何客户端提供服务，没有会话关联或粘性会话.相关的会话信息存储在客户端，并根据需要传递给服务器.
这并不妨碍 Web 服务器与之通信的其他服务维护有关业务对象(例如购物车)的状态，只是不妨碍客户端的当前应用程序/会话状态.
客户端的应用程序状态不应该存储在服务器上，而是从客户端传递到每个需要它的地方.
这就是 REST 中的 ST 的来源，状态转移.您转移状态而不是让服务器存储它.这是扩展到数百万并发用户的唯一方法.如果不是因为数百万会话就是数百万会话.
会话管理的负载在所有客户端上分摊，客户端存储其会话状态，服务器可以以无状态方式为多个数量级或更多客户端提供服务.
即使对于您认为 只 需要在 10 多个并发用户中使用的服务，您仍然应该使您的服务无状态.数万还是数万，会产生与之相关的时间和空间成本.
无状态是 HTTP 协议和网络的一般设计方式，是一种整体更简单的实现，您有一个单一的代码路径，而不是一堆服务器端逻辑来维护一堆会话状态.
有一些非常基本的实现原则:
这些是原则而不是实现，您如何满足这些原则可能会有所不同.
总而言之，五项关键原则是:
- 给每个事物"一个 ID
- 将事物联系在一起
- 使用标准方法
- 具有多种表现形式的资源
- 无状态通信
REST 论文中没有关于身份验证或授权的内容.
因为对 RESTful 请求和非 RESTful 请求进行身份验证没有什么不同.身份验证与 RESTful 讨论无关.
解释如何为您的特定要求创建无状态应用程序，对于 StackOverflow 来说过于宽泛.
实现与 REST 相关的身份验证和授权更加过于宽泛，互联网上对各种实现方法进行了详细解释.
<块引用>寻求帮助/信息的评论将/应该被标记为不再需要.
I'm in need of some clarification. I've been reading about REST, and building RESTful applications. According to wikipedia, REST itself is defined to be Representational State Transfer. I therefore don't understand all this stateless gobbledeygook that everyone keeps spewing.
From wikipedia:
At any particular time, a client can either be in transition between application states or "at rest". A client in a rest state is able to interact with its user, but creates no load and consumes no per-client storage on the set of servers or on the network.
Are they just saying don't use session/application level data store???
I get that one goal of REST is to make URI access consistent and available, for instance, instead of hiding paging requests inside posts, making the page number of a request a part of the GET URI. Makes sense to me. But it seems like it is just going overboard saying that no per client data (session data) should ever be stored server side.
What if I had a queue of messages, and my user wanted to read the messages, but as he read them, wanted to block certain senders messages coming through for the duration of his session? Wouldn't it make sense to store this in a place on the server side, and have the server only send messages (or message ID's) that were not blocked by the user?
Do I really have to send the entire list of message senders to block each time I request the new message list? The message list pertinent to me wouldn't/shouldn't even be a publicly available resource in the first place..
Again, just trying to understand this. Someone please clarify.
Update:
I have found a stack overflow question that has an answer that doesn't quite get me all the way there: How to manage state in REST which says that the client state that is important should all be transferred on every request.... Ugg.. seems like a lot of overhead... Is this right??
The fundamental explanation is:
No client session state on the server.
By stateless it means that the server does not store any state about the client session on the server side.
The client session is stored on the client. The server is stateless means that every server can service any client at any time, there is no session affinity or sticky sessions. The relevant session information is stored on the client and passed to the server as needed.
That does not preclude other services that the web server talks to from maintaining state about business objects such as shopping carts, just not about the client's current application/session state.
The client's application state should never be stored on the server, but passed around from the client to every place that needs it.
That is where the ST in REST comes from, State Transfer. You transfer the state around instead of having the server store it. This is the only way to scale to millions of concurrent users. If for no other reason than because millions of sessions is millions of sessions.
The load of session management is amortized across all the clients, the clients store their session state and the servers can service many orders of magnitude or more clients in a stateless fashion.
Even for a service that you think will only need in the 10's of thousands of concurrent users, you still should make your service stateless. Tens of thousands is still tens of thousands and there will be time and space cost associated with it.
Stateless is how the HTTP protocol and the web in general was designed to operate and is an overall simpler implementation and you have a single code path instead of a bunch of server side logic to maintain a bunch of session state.
There are some very basic implementation principles:
These are principles not implementations, how you meet these principles may vary.
In summary, the five key principles are:
- Give every "thing" an ID
- Link things together
- Use standard methods
- Resources with multiple representations
- Communicate statelessly
There is nothing about authentication or authorization in the REST dissertation.
Because there is nothing different from authenticating a request that is RESTful from one that is not. Authentication is irrelevant to the RESTful discussion.
Explaining how to create a stateless application for your particular requirements, is too-broad for StackOverflow.
Implementing Authentication and Authorization as it pertains to REST is even more so too-broad and various approaches to implementations are explained in great detail on the internet in general.
Comments asking for help/info on this will/should just be flagged as No Longer Needed.
这篇关于如果 REST 应用程序应该是无状态的，您如何管理会话?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
