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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

希望这能有所帮助!

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

REST非常抽象。有一些好的、简单的、真实的例子是有帮助的。

以所有主要的社交媒体应用程序为例——Tumblr、Instagram、Facebook和Twitter。它们都有一个永远滚动的视图，你往下滚动得越远，你看到的内容就越多，时间也越来越久远。然而，我们都经历过这样的时刻，你失去了你滚动到的位置，应用程序将你重置回顶部。比如，如果你退出了应用程序，那么当你重新打开它时，你又回到了顶部。

原因是服务器没有存储您的会话状态。遗憾的是，您的滚动位置只是存储在客户端的RAM中。

幸运的是，重新连接时不必重新登录，但这只是因为客户端存储的登录证书还没有过期。删除并重新安装应用程序，你将不得不重新登录，因为服务器没有将你的IP地址与你的会话关联。

服务器上没有登录会话，因为它们遵循REST。

现在，上面的例子根本不涉及web浏览器，但在后端，应用程序通过HTTPS与它们的主机服务器通信。我的观点是REST不必涉及cookie和浏览器等。存储客户端会话状态的方法多种多样。

但是让我们来讨论一下web浏览器，因为它带来了REST的另一个主要优势，这里没有人谈论这个优势。

如果服务器试图存储会话状态，它应该如何识别每个单独的客户机?

它不能使用他们的IP地址，因为许多人可以在共享路由器上使用相同的地址。那怎么做呢?

它不能使用MAC地址的原因有很多，最重要的是你可以在不同的浏览器和应用程序上同时登录多个不同的Facebook账户。一个浏览器可以很容易地伪装成另一个浏览器，MAC地址也很容易被欺骗。

If the server has to store some client-side state to identify you, it has to store it in RAM longer than just the time it takes to process your requests, or else it has to cache that data. Servers have limited amounts of RAM and cache, not to mention processor speed. Server-side state adds to all three, exponentially. Plus if the server is going to store any state about your sessions then it has to store it separately for each browser and app you're currently logged in with, and also for each different device you use.

所以…我希望您现在明白为什么REST对于可伸缩性如此重要。 我希望您可以开始理解为什么服务器端会话状态之于服务器可伸缩性，就像焊接铁砧之于汽车加速。

人们感到困惑的地方是认为“状态”指的是存储在数据库中的信息。不，它指的是当您使用服务器RAM时需要存储在它中的任何信息。

最基本的解释是:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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