我需要一些澄清。我一直在阅读关于REST和构建基于REST的应用程序的书籍。根据维基百科,REST本身被定义为具象状态传输。因此,我不理解所有这些无国籍的官样文章,每个人都在不停地吐出来。

从维基百科:

在任何特定的时间,客户端可以处于之间的转换 应用程序处于“静止”状态。处于休息状态的客户端可以 与用户交互,但不创建负载,也不消耗每个客户端 服务器集或网络上的存储。

他们只是说不要使用会话/应用程序级数据存储吗?

我知道REST的一个目标是使URI访问一致且可用,例如,不是在帖子中隐藏分页请求,而是使请求的页码成为get URI的一部分。对我来说很有道理。但是,说每个客户端数据(会话数据)都不应该存储在服务器端似乎有点过头了。

如果我有一个消息队列,而我的用户想要读取消息,但在读取消息时,又想在会话期间阻止某些发送者的消息通过,该怎么办?将其存储在服务器端的某个位置,并让服务器只发送未被用户阻止的消息(或消息ID),这难道不合理吗?

每次请求新的消息列表时,我真的必须发送整个消息发送者列表来阻止吗?与我相关的消息列表在一开始就不应该是公开可用的资源。

我只是想理解一下。谁来澄清一下。


更新:

我发现了一个堆栈溢出的问题,它的答案并不能让我一直走到那里: 如何在REST中管理状态 这说明客户端状态很重要,应该在每个请求上都传输....Ugg . .看起来开销很大…这样对吗??


当前回答

Stateless means the state of the service doesn’t persist between subsequent requests and response. Each request carries its own user credentials and is individually authenticated. But in stateful each request is known from any prior request. All stateful requests are session-oriented i.e. each request need to know and retain changes made in previous requests. Banking application is an example of stateful application. Where user first login then make transaction and logs out. If after logout user will try to make the transaction, he will not be able to do so. Yes, http protocol is essentially a stateless protocol but to make it stateful we make us of HTTP cookies. So, is SOAP by default. But it can be make stateful likewise, depends upon framework you are using. HTTP is stateless but still we can maintain session in our java application by using different session tracking mechanism. Yes, We can also maintain session in webservice whether it is REST or SOAP. It can be implemented by using any third party library or you can implement by our own.

摘自http://gopaldas.org/webservices/soap/webservice-is-stateful-or-stateless-rest-soap

其他回答

他们只是说不要使用会话/应用程序级数据存储吗?

不。他们不是在用一种无关紧要的方式说。

他们说不要定义“会话”。不登录。不注销。为请求提供凭据。每个请求都是独立的。

您仍然有数据存储。您仍然拥有身份验证和授权。您只是不需要浪费时间建立会话和维护会话状态。

关键在于,每个请求(a)都是完全独立的,(b)可以简单地外包给一个巨大的并行服务器群,而不需要任何实际工作。Apache或Squid可以盲目且成功地传递RESTful请求。

如果我有一个消息队列,而我的用户想要读取消息,但在读取消息时,又想在会话期间阻止某些发送者的消息通过,该怎么办?

如果用户需要一个过滤器,那么只需在每个请求上提供过滤器。

难道……不合理吗?服务器是否只发送未被用户阻止的消息(或消息ID) ?

是的。在RESTful URI请求中提供筛选器。

每次请求新的消息列表时,我真的必须发送整个消息发送者列表来阻止吗?

是的。这个“要阻止的消息发送者列表”可以有多大?一个简短的PK列表?

GET请求可以非常大。如果有必要,您可以尝试POST请求,尽管它听起来像一种查询。

您必须在客户端管理客户端会话。这意味着您必须在每个请求中发送身份验证数据,并且您可能(但不一定)在服务器上有一个内存缓存,它将身份验证数据与用户信息(如身份、权限等)配对。

这种REST无状态约束非常重要。如果不应用此约束,您的服务器端应用程序将不能很好地扩展,因为维护每个客户机会话将是它的阿喀琉斯之踵。

我知道这里的基本问题是混淆了会议和国家。虽然REST指定不应该在服务器上存储状态,但没有什么可以阻止您存储用户会话。

管理服务器上的状态意味着您的服务器确切地知道客户机正在做什么(它们正在应用程序的哪个部分中查看哪个页面)。这是你不需要做的。

我同意其他人的说法,你应该保持会话存储的最小大小;虽然这是常识,但实际上也取决于应用程序。 因此,简而言之,您仍然可以保留一个带有缓存数据的会话,以较小的服务器负载处理请求,并通过提供一个临时身份验证/访问令牌供客户机使用来管理身份验证。每当会话/令牌过期时,生成一个新的会话/令牌,并要求客户端使用它。

有人可能会说,客户端应该更好地生成令牌。我说它是双向工作的,这取决于应用程序,以及谁将使用API。

在服务器上保留一些敏感的会话数据也是正确的做法。例如,您不能相信客户端会保留包含名为“isFreeGift”字段的购物车。这些信息应该保存在服务器上。

Santanu Dey在回答中提供的视频链接很有帮助。如果你还没看过,就看看吧。

只是一个旁注:似乎所有已经给出的答案都忽略了一个事实,即某些操作可能会导致服务器负载过重。这与功耗、硬件消耗和成本(对于按CPU周期租用的服务器)有关。一个优秀的开发人员不应该懒惰地优化他们的应用程序,即使操作可以在一些租用的服务器上的现代CPU上快速完成,而且他们不需要支付电费和维护费用。

虽然这个问题是几年前的事了,但我希望我的回答仍然会有帮助。

The whole concept is different... You don't need to manage sessions if you are trying to implement RESTFul protocol. In that case it is better to do authentication procedure on every request (whereas there is an extra cost to it in terms of performance - hashing password would be a good example. not a big deal...). If you use sessions - how can you distribute load across multiple servers? I bet RESTFul protocol is meant to eliminate sessions whatsoever - you don't really need them... That's why it is called "stateless". Sessions are only required when you cannot store anything other than Cookie on a client side after a reqest has been made (take old, non Javascript/HTML5-supporting browser as an example). In case of "full-featured" RESTFul client it is usually safe to store base64(login:password) on a client side (in memory) until the applictation is still loaded - the application is used to access to the only host and the cookie cannot be compromised by the third party scripts...

我强烈建议禁用RESTFul服务的cookie认证…检查Basic/Digest Auth -这对于基于rest的服务应该足够了。

这里的无状态意味着请求的状态或元数据不在服务器端维护。通过在服务器上维护每个请求或用户的状态,将导致性能瓶颈。服务器只是被请求提供执行任何特定操作所需的属性。

对于会话管理,或者为用户提供自定义体验,需要维护一些元数据或用户状态,可能是用户的偏好,过去的请求历史。这可以通过维护cookie、隐藏属性或进入会话对象来完成。

这可以维护或跟踪用户在应用程序中的状态。

希望这能有所帮助!