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

从维基百科:

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

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

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

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

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

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


更新:

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


当前回答

没有勺子。

不要把无状态想象成“一次又一次地把你所有的东西发送到服务器”。不可能。总会有状态——数据库本身也是一种状态,毕竟你是注册用户,所以没有服务器端,任何客户端信息都是无效的。从技术上讲,您从来都不是真正无状态的。

关于登录的争论

不保持会话并每次都登录是什么意思? 有些意思是“每次都发送密码”,这太愚蠢了。有些人说“不,当然不是,而是发送一个令牌”——你瞧,PHP会话就是这么做的。它发送一个会话id,这是一种令牌,它可以帮助你到达你的个人物品,而不必每次都重发u/pw。它也非常可靠,并且经过了良好的测试。是的,方便也会变成缺点,见下一段。

减少碳足迹

What you should do, instead, and what makes real sense, is thin your webserver footprint to the minimum. Languages like PHP make it very easy to just stuff everything in the session storage - but sessions have a price tag. If you have several webservers, they need to share session info, because they share the load too - any of them may have to serve the next request. A shared storage is a must. Server needs to know at least if someone's logged in or not. (And if you bother the database every time you need to decide this, you're practically doomed.) Shared storages need to be a lot faster than the database. This brings the temptation: okay, I have a very fast storage, why not do everything there? - and that's where things go nasty in the other way.

你的意思是,保持会话存储最小?

Again, it's your decision. You can store stuff there for performance reasons (database is almost always slower than Redis), you can store information redundantly, implement your own caching, whatever - just keep in mind that web servers will have a bigger load if you store a lot of rubbish on them. Also, if they break under heavy loads (and they will), you lose valuable information; with the REST way of thinking, all that happens in this case is the client sends the same (!) request again and it gets served this time.

那该怎么做呢?

No one-fits-all solution here. I'd say choose a level of statelessness and go with that. Sessions may be loved by some and hated by others but they're not going anywhere. With every request, send as much information as makes sense, a bit more perhaps; but don't interpret statelessness as not having a session, nor as logging in every time. Somehow the server must know it's you; PHP session ids are one good way, manually generated tokens are another. Think and decide - don't let design trends think for you.

其他回答

在开发RESTful服务时,为了登录,您需要对用户进行身份验证。一种可能的选择是在每次执行用户操作时发送用户名和密码。在这种情况下,服务器将根本不存储会话数据。

Another option is to generate a session-id on the server and send it to the client, so the client will be able to send session-id to the server and authenticate with that. This is much much safer than sending username and password each time, since if somebody gets their hand on that data, then he/she can impersonate the user until the username and password is changed. You may say that even the session id can be stolen and the user will be impersonated in that case and you are right. However, in this case impersonating the user will only be possible while the session id is valid.

如果RESTful API需要用户名和密码才能更改用户名和密码,那么即使有人使用会话id冒充用户,黑客也无法锁定真正的用户。

会话id可以通过单向锁定(加密)某个标识用户的东西并将时间添加到会话id中来生成,这样就可以定义会话的过期时间。

The server may or may not store session ids. Of course, if the server stores the session id, then it would violate the criteria defined in the question. However, it is only important to make sure that the session id can be validated for the given user, which does not necessitate storing the session id. Imagine a way that you have a one-way-encryption of email, user id and some user-specific private data, like favorite color, this would be the first level and somehow adding the username date to the encrypted string and apply a two-way encryption. As a result when a session id is received, the second level could be decrypted to be able to determine which username the user claims to be and whether the session time is right. If this is valid, then the first level of encryption could be validated by doing that encryption again and checking whether it matches the string. You do not need to store session data in order to achieve that.

您完全正确,支持与服务器的完全无状态交互确实给客户机增加了额外的负担。但是,如果考虑扩展应用程序,客户机的计算能力与客户机的数量成正比。因此,扩展到大量的客户是更加可行的。

只要您让服务器负责管理与特定客户端交互相关的一些信息,这个负担就会迅速增长到消耗服务器。

这是一种权衡。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

REST is stateless and doesn’t maintain any states between the requests. Client cookies / headers are set to maintain the user state like authentication. Say Client username/password are validated by third part authentication mechanism – 2nd level OTP gerneation etc. Once user get authenticated – headers /cookies comes to rest service end point exposed and we can assume user as auth since user is coming with valid headers/cookies. Now certain info of user like IP is either maintained in the cache and after that if request is coming from same Ip (mac address) for listed resources User is allowed. And cache is maintained for some particular time which get invalidated once time lapses. So either cache can be used or DB entries can be used to persist info b/w the requests.