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的服务应该足够了。

没有勺子。

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

关于登录的争论

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

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.

无状态和有状态的主要区别在于每次都将数据传递回服务器。在无状态的情况下，客户端必须提供所有的信息，所以很多参数可能需要在每个请求中传递。在有状态的情况下，cliet只传递一次这些参数，它们由服务器维护，直到客户端再次修改。

在我看来，API应该是无状态的，这允许快速扩展。

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

最基本的解释是:

服务器上没有客户端会话状态。

无状态意味着服务器不在服务器端存储任何关于客户端会话的状态。

客户端会话存储在客户端上。服务器无状态意味着每个服务器可以在任何时间服务任何客户端，不存在会话关联或会话保持。相关的会话信息存储在客户机上，并根据需要传递给服务器。

这并不妨碍与web服务器通信的其他服务维护有关业务对象(如购物车)的状态，而不是有关客户端当前应用程序/会话状态的状态。

客户端的应用程序状态永远不应该存储在服务器上，而是从客户端传递到每个需要它的地方。

这就是REST中的ST(状态传输)的由来。您传递状态，而不是让服务器存储它。这是扩展到数百万并发用户的唯一方法。如果没有别的原因，只是因为数百万次会话就是数百万次会话。

会话管理的负载被分摊到所有客户机上，客户机存储它们的会话状态，服务器可以以无状态的方式为多个数量级或更多的客户机提供服务。

即使对于一个您认为只需要成千上万并发用户的服务，您仍然应该使您的服务无状态。几万还是几万，会有时间和空间成本。

无状态是HTTP协议和web一般设计的操作方式，是一个总体上更简单的实现，您有一个单一的代码路径，而不是一堆服务器端逻辑来维护一堆会话状态。

这里有一些非常基本的实现原则:

这些是原则而不是实现，你如何满足这些原则可能会有所不同。

总而言之，五个主要原则是:

给每件“东西”一个ID 把事物联系起来 使用标准方法 具有多个表示形式的资源 无状态通信

REST论文中没有任何关于身份验证或授权的内容。

因为验证RESTful请求与验证非RESTful请求并没有什么不同。身份验证与RESTful讨论无关。

解释如何为您的特定需求创建无状态应用程序，对于StackOverflow来说太宽泛了。

实现与REST相关的身份验证和授权甚至过于宽泛，一般在互联网上详细解释了各种实现方法。

寻求帮助/信息的评论将/应该被标记为 不再需要。