如果 REST 应用程序应该是无状态的，那么您如何管理会话？

基本解释是：

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

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

客户端会话存储在客户端上。服务器是无状态的，这意味着每个服务器都可以随时为任何客户端提供服务，没有会话亲和性或粘性会话。相关的会话信息存储在客户端，并根据需要传递给服务器。

这并不排除 Web 服务器与之交谈的其他服务维护有关诸如购物车之类的业务对象的状态，只是不排除有关客户端当前应用程序/会话状态的状态。

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

这就是 REST 中的 ST 的来源，State Transfer。您转移状态而不是让服务器存储它。这是扩展到数百万并发用户的唯一方法。如果没有其他原因，因为数百万次会话就是数百万次会话。

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

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

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

有一些非常基本的实现原则：

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

总之，five key principles 是：

给每个“事物”一个 ID 将事物链接在一起 使用标准方法 具有多种表示的资源 无状态通信

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

因为认证一个 RESTful 的请求和一个非 RESTful 的请求没有什么不同。身份验证与 RESTful 讨论无关。

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

实现与 REST 相关的身份验证和授权更加广泛，并且在互联网上一般都非常详细地解释了各种实现方法。

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

---

无状态意味着每个 HTTP 请求都是在完全隔离的情况下发生的。当客户端发出 HTTP 请求时，它包含服务器完成该请求所需的所有信息。服务器从不依赖来自先前请求的信息。如果该信息很重要，客户端将不得不在后续请求中再次发送。无状态也带来了新的功能。在负载平衡的服务器之间分发无状态应用程序更容易。无状态应用程序也很容易缓存。

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

当您实际发出请求时，Web 服务只需要关心您的应用程序状态。其余时间，它甚至不知道你的存在。这意味着每当客户端发出请求时，它必须包含服务器需要处理它的所有应用程序状态。

每个客户端的资源状态都是相同的，它的正确位置是在服务器上。当您将图片上传到服务器时，您会创建一个新资源：新图片有自己的 URI，并且可以成为未来请求的目标。您可以通过 HTTP 获取、修改和删除此资源。

希望这有助于区分无国籍和各种状态的含义。

---

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

不，他们并没有以微不足道的方式这么说。

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

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

关键是每个请求 (a) 完全独立，并且 (b) 可以很容易地被外包到一个巨大的并行服务器场，而无需任何实际工作。 Apache 或 Squid 可以盲目且成功地传递 RESTful 请求。

如果我有一个消息队列，并且我的用户想要阅读这些消息，但是当他阅读它们时，想要在他的会话期间阻止某些发件人消息通过，该怎么办？

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

难道......让服务器只发送未被用户阻止的消息（或消息ID）没有意义吗？

是的。在 RESTful URI 请求中提供过滤器。

每次我请求新的邮件列表时，我真的必须发送整个邮件发件人列表来阻止吗？

是的。这个“要阻止的消息发件人列表”有多大？ PK的简短列表？

GET 请求可能非常大。如有必要，您可以尝试 POST 请求，即使它听起来像是一种查询。

---

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

一旦您将一点点责任放在服务器上来管理与特定客户端交互相关的一些信息，这种负担就会迅速增长到消耗服务器。

这是一个权衡。

---

用户应用状态管理历史视图

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

这种需要的原因是客户端缺乏标准来有效地维护状态，而无需制作特定于客户端（即特定于浏览器）的应用程序或插件。

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

REST 服务的一般用法

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

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

认证

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

REST 服务不使用基于表单的身份验证。但是，如上所述，REST 服务不是由用户调用，而是由应用程序调用。应用程序需要管理获取身份验证令牌。在我的例子中，我使用带有 JASPIC with OAuth 2.0 to connect to Google for authentication 的 cookie 和简单的 HTTP 身份验证来进行自动化测试。我还使用 HTTP Header authentication via JASPIC 进行本地测试（尽管可以在 SiteMinder 中执行相同的方法）

根据这些示例，身份验证在客户端进行管理（尽管 SiteMinder 或 Google 会将身份验证会话存储在其端），对此状态无能为力，但它不是 REST 服务应用程序的一部分。

检索请求

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

事务脚本

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

这对于 REST 服务意味着 [如果正确完成] 是向 REST 服务器发出单个请求，该请求将包含单个用户操作所需的所有内容，该操作执行单个事务中所需的所有操作，Transaction Script 是模式被称为。

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

许多人为设计的 REST 示例（我自己做了这个）试图尽可能多地遵循 HTTP 协议中定义的内容，在经历了这些之后，我决定更加务实并将其留给 GET and POST only。 POST 方法甚至不必实现 POST-REDIRECT-GET 模式。

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

轮询

虽然 REST 也可以用于轮询，但我不会推荐它，除非因为浏览器兼容性而必须使用它。为此，我将使用我也为其设计了 API contract 的 WebSockets。旧浏览器的另一个替代方案是 CometD。

---

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

以所有主要的社交媒体应用程序为例——Tumblr、Instagram、Facebook 和 Twitter。它们都有一个永远滚动的视图，你向下滚动的越远，你看到的内容就越多，而且时间越长。但是，我们都经历过您失去滚动到的位置的那一刻，该应用程序会将您重置回顶部。就像你退出应用程序，然后当你重新打开它时，你又回到了顶部。

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

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

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

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

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

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

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

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

如果服务器必须存储一些客户端状态来识别您，它必须将其存储在 RAM 中，而不仅仅是处理您的请求所需的时间，否则它必须缓存该数据。服务器的 RAM 和缓存数量有限，更不用说处理器速度了。服务器端状态以指数方式添加到所有三个中。另外，如果服务器要存储有关您的会话的任何状态，那么它必须为您当前登录的每个浏览器和应用程序以及您使用的每个不同设备单独存储它。

所以...我希望你现在明白为什么 REST 对可扩展性如此重要。我希望你能开始明白为什么服务器端会话状态对服务器可扩展性的影响就像焊接铁砧对汽车加速的影响一样。

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

---

没有勺子。

不要将无状态视为“一次又一次地将所有东西发送到服务器”。没门。总会有状态——数据库本身毕竟是一种状态，你是注册用户，所以任何一组客户端信息在没有服务器端的情况下都是无效的。从技术上讲，你永远不是真正的无国籍人。

登录辩论

减少占地面积

所以你是说，将会话存储保持在最低限度？

那怎么办呢？

---

我看到这里的基本问题是将 Session 与 State 混为一谈。虽然 REST 指定您不应该将状态存储在服务器上，但没有什么可以阻止您存储用户会话。

在服务器上管理状态意味着您的服务器确切地知道客户端在做什么（他们在应用程序的哪个部分查看哪个页面）。这是你不应该做的。

我同意其他人的观点，即您应该将会话存储保持在最小大小；虽然这是常识，但它实际上也取决于应用程序。因此，简而言之，您仍然可以与缓存数据保持会话，以在服务器上以较少的负载处理请求，并通过提供临时身份验证/访问令牌供客户端使用来管理身份验证。每当会话/令牌过期时，生成一个新的并要求客户端使用它。

有人可能会争辩说客户端应该更好地生成令牌。我说它是双向的，它取决于应用程序，以及谁将使用 API。

此外，在服务器上保留一些敏感的会话数据应该是正确的做法。您不能相信客户会保留他们的购物车（例如）包含名为“isFreeGift”的字段。此类信息应保存在服务器上。

Santanu Dey 在他的回答中提供的视频链接很有帮助。如果你还没有，请关注它。

附带说明：似乎所有已经给出的答案似乎都忽略了某些操作可能导致服务器负载过重的事实。这与功耗、硬件消耗和成本相关（对于按 CPU 周期租用的服务器）。一个优秀的开发人员不应该偷懒优化他们的应用程序，即使操作可以在一些租用的服务器上的现代 CPU 上非常快速地完成，而他们不支付电费和维护费用。

尽管这个问题已经有几年了，但我希望我的回答仍然会有所帮助。

---

无状态意味着服务的状态不会在后续请求和响应之间持续存在。每个请求都带有自己的用户凭据，并单独进行身份验证。但是在有状态的情况下，每个请求都是从任何先前的请求中得知的。所有有状态的请求都是面向会话的，即每个请求都需要知道并保留在先前请求中所做的更改。银行应用程序是有状态应用程序的一个示例。用户首先登录然后进行交易并注销。如果注销后用户将尝试进行交易，他将无法这样做。是的，http 协议本质上是一个无状态协议，但为了使其有状态，我们使用了 HTTP cookie。因此，默认情况下是 SOAP。但它也可以是有状态的，这取决于您使用的框架。 HTTP 是无状态的，但我们仍然可以通过使用不同的会话跟踪机制在我们的 java 应用程序中维护会话。是的，我们也可以在 Web 服务中维护会话，无论是 REST 还是 SOAP。它可以使用任何第三方库来实现，也可以由我们自己实现。

取自 http://gopaldas.org/webservices/soap/webservice-is-stateful-or-stateless-rest-soap

---

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

IMO，API 应该是无状态的，这允许快速扩展。

---

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

这个 REST statelessness constraint 非常重要。如果不应用此约束，您的服务器端应用程序将无法很好地scale，因为维护每个单独的客户端会话将是它的 Achilles' heel。

---

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

另一种选择是在服务器上生成一个 session-id 并将其发送给客户端，这样客户端就可以将 session-id 发送到服务器并对其进行身份验证。这比每次发送用户名和密码要安全得多，因为如果有人掌握了该数据，那么他/她可以冒充用户，直到用户名和密码被更改。您可能会说即使会话 id 也可能被盗，在这种情况下用户将被冒充，您是对的。但是，在这种情况下，只有在会话 ID 有效时才能模拟用户。

如果 RESTful API 需要用户名和密码来更改用户名和密码，那么即使有人使用会话 ID 冒充用户，黑客也无法锁定真实用户。

会话 ID 可以通过单向锁定（加密）识别用户的东西并将时间添加到会话 ID 来生成，这样可以定义会话的到期时间。

服务器可能会也可能不会存储会话 ID。当然，如果服务器存储会话 id，那么它将违反问题中定义的标准。但是，重要的是确保可以为给定用户验证会话 ID，这不需要存储会话 ID。想象一种方式，您对电子邮件、用户 ID 和一些特定于用户的私人数据（如最喜欢的颜色）进行单向加密，这将是第一级，并以某种方式将用户名日期添加到加密字符串并应用两个-方式加密。因此，当接收到会话 id 时，可以对第二级进行解密，以便能够确定用户声称是哪个用户名以及会话时间是否正确。如果这是有效的，则可以通过再次进行该加密并检查它是否与字符串匹配来验证第一级加密。您无需存储会话数据即可实现这一目标。

---

整个概念是不同的......如果您尝试实现 RESTFul 协议，则不需要管理会话。在这种情况下，最好对每个请求执行身份验证程序（而在性能方面需要额外的成本 - 散列密码将是一个很好的例子。没什么大不了的......）。如果您使用会话 - 如何在多个服务器之间分配负载？我敢打赌 RESTFul 协议旨在消除任何会话 - 你并不真的需要它们......这就是为什么它被称为“无状态”。仅当您在提出请求后无法在客户端存储除 Cookie 之外的任何内容时（以旧的、不支持 Javascript/HTML5 的浏览器为例），才需要会话。在“全功能”RESTFul 客户端的情况下，将 base64(login:password) 存储在客户端（在内存中）通常是安全的，直到仍然加载应用程序 - 应用程序用于访问唯一的主机并且 cookie 不会受到损害由第三方脚本...

我强烈建议禁用 RESTFul 服务的 cookie 身份验证...查看 Basic/Digest Auth - 这对于基于 RESTFul 的服务应该足够了。

---

REST 是无状态的，不维护请求之间的任何状态。客户端 cookie / 标头设置为维护用户状态，如身份验证。假设客户端用户名/密码通过第三方身份验证机制进行验证 - 二级 OTP 生成等。一旦用户通过身份验证 - 标头 /cookies 进入休息服务端点暴露，我们可以假设用户为身份验证，因为用户带有有效的标头/cookies .现在，用户的某些信息（如 IP）要么保存在缓存中，然后如果请求来自列出的资源的相同 IP（mac 地址），则允许用户。并且缓存会保留一段时间，一旦时间流逝，这些特定时间就会失效。因此，既可以使用缓存，也可以使用数据库条目来保存请求信息。

---

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

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

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

希望这可以帮助！

---