静态服务如何识别哪个用户调用哪种方法，以及如何使静态服务变为有状态？

Question

由于宁静的服务是stateless ，它不维护用户的任何交互，所以我想知道是否有多个用户访问相同的宁静的服务，那么restful service如何识别哪个用户与哪种方法交互？ 是否有可能使静态服务成为stateful ？

Answer 1

哪个用户：

通过使用在服务器上创建并随每个下一个请求返回的共享机密（一行字符）。

它已“保存”在cookie中，并由客户端使用cookie或HTTP（S）标头返回。

哪种方法：

这取决于您使用的框架。 但是最终归结为将URI映射到您的方法。

是否有可能使静态服务成为有状态的？

您可以制作有状态的应用程序，然后它们就不会静止。 一个宁静的应用程序是无状态的。 这就是定义，因此您可以制作有状态的应用程序，但永远不能创建有状态的rest-app，因为rest是无状态的。

Answer 2

根据我的观点，Restful Web服务使之成为无状态的。它的体系结构样式具有一组约束和属性，因此无状态是其属性，我们无法更改其属性，因此这并不意味着Restful服务是有状态的。

我们可以将URI映射到您的方法，然后轻松知道哪个用户正在调用哪个方法。

Answer 3

tl; dr

客户端必须存储自己的会话状态，并在每个请求中将其传递给服务器。

REST架构样式的无状态约束定义如下：

5.1.3无状态

客户端到服务器的每个请求都必须包含理解该请求所需的所有信息，并且不能利用服务器上任何已存储的上下文。 因此，会话状态完全保留在客户端上。 [...]

如果客户端请求需要身份验证的受保护资源，则每个请求都必须包含所有必要的数据，以便正确地进行身份验证/授权。 请参阅RFC 7235中的此引用：

假定HTTP认证是无状态的：认证请求所必需的所有信息都必须在请求中提供，而不是依赖于服务器记住先前的请求。

身份验证数据应属于标准的HTTP授权标头。 从RFC 7235中：

4.2。 授权书

Authorization标头字段允许用户代理通过源服务器对自身进行身份验证-通常但不一定是在收到401 （未授权）响应之后。 它的值由凭证组成，凭证包含用于所请求资源领域的用户代理的身份验证信息。 [...]

^{这个HTTP标头的名称很不幸，因为它带有身份验证而不是授权数据。}

对于身份验证，可以使用基本HTTP身份验证方案，该方案将凭据作为用户名和密码对传输，并使用Base64编码：

Authorization: Basic <credentials>

如果您不想在每个请求中发送用户名和密码，则可以将用户名和密码交换为在每个请求中发送的令牌（例如JWT ）。 JWT令牌可以包含用户名，有效期和与您的应用程序相关的任何其他元数据：

Authorization: Bearer <token>

有关更多详细信息，请参见此答案。