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

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

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协议获取、修改和删除该资源。

最基本的解释是:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

实现与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时需要存储在它中的任何信息。

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

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

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

随着时间的推移，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。

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.