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

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

这是一种权衡。

在开发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.

Statelessness means that every HTTP request happens in complete isolation. When the client makes an HTTP request, it includes all the information necessary for the server to fulfill that request. The server never relies on information from previous requests. If that information was important, the client would have to send it again in subsequent request. Statelessness also brings new features. It’s easier to distribute a stateless application across load-balanced servers. A stateless application is also easy to cache.

实际上有两种状态。客户机上的应用程序状态和服务器上的资源状态。

web服务只需要在实际发出请求时关心应用程序的状态。其他时候，它甚至不知道你的存在。这意味着无论客户端何时发出请求，都必须包含服务器处理请求所需的所有应用程序状态。

每个客户机的资源状态都是相同的，它的适当位置在服务器上。当您将图片上传到服务器时，您创建了一个新资源:新图片有自己的URI，可以作为未来请求的目标。您可以通过HTTP协议获取、修改和删除该资源。

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

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

这是一种权衡。

用户应用程序状态管理的历史视图

传统意义上的会话将用户的状态保存在服务器内部的应用程序中。这可能是流中的当前页面，也可能是先前已输入但尚未持久化到主数据库中的内容。

这种需求的原因是客户端缺乏有效维护状态的标准，而不需要特定于客户端(即特定于浏览器)的应用程序或插件。

随着时间的推移，HTML5和XML Header Request已经标准化了在客户端(即浏览器端)以标准方式存储包括应用程序状态在内的复杂数据的概念，而无需在服务器之间来回传输。

REST服务的一般使用

REST服务通常在需要执行事务或需要检索数据时调用。

REST服务应该由客户端应用程序调用，而不是由最终用户直接调用。

进行身份验证

对于任何对服务器的请求，请求的一部分应该包含授权令牌。它是如何实现的是特定于应用程序的，但通常是BASIC或CERTIFICATE形式的身份验证。

Form based authentication is not used by REST services. However, as noted above REST services are not meant to be called by the user, but by the application. The application needs to manage getting the authentication token. In my case I used cookies with JASPIC with OAuth 2.0 to connect to Google for authentication and simple HTTP Authentication for automated testing. I also used HTTP Header authentication via JASPIC for local testing as well (though the same approach can be performed in SiteMinder)

根据这些示例，身份验证是在客户端进行管理的(尽管SiteMinder或谷歌将在其端存储身份验证会话)，对于该状态无法做任何事情，但它不是REST服务应用程序的一部分。

检索请求

REST中的检索请求是GET操作，其中请求特定的资源并且是可缓存的。不需要服务器会话，因为请求拥有检索数据所需的一切:身份验证和URI。

事务脚本

如上所述，客户端应用程序本身调用REST服务以及它在客户端管理的身份验证。

这对于REST服务(如果操作正确的话)意味着将单个请求发送到REST服务器，该服务器将包含单个用户操作所需的所有内容，该操作执行单个事务所需的所有内容，事务脚本就是该模式的名称。

这通常通过POST请求来完成，但也可以使用其他请求，如PUT。

很多人为的REST示例(我自己做过)试图尽可能多地遵循HTTP协议中定义的内容，在经历了这些之后，我决定更加务实，只把它留给GET和POST。POST方法甚至不需要实现POST- redirect - get模式。

尽管如此，正如我上面提到的，客户端应用程序将是调用服务的应用程序，它只在需要时(不是每次)调用带有所有数据的POST请求。这可以防止对服务器的不断请求。

轮询

尽管REST也可以用于轮询，但我不推荐使用它，除非出于浏览器兼容性的考虑必须使用它。为此，我将使用WebSockets，我也为它设计了API契约。旧浏览器的另一个替代方案是CometD。

没有勺子。

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

关于登录的争论

不保持会话并每次都登录是什么意思? 有些意思是“每次都发送密码”，这太愚蠢了。有些人说“不，当然不是，而是发送一个令牌”——你瞧，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.