rest - 如何理解 "RESTful API is stateless"？

Question

我听说“ RESTful API 应该是无状态的。所有状态信息都应该保存在客户端 ”。
但是当我从网页发出 AJAX 调用时，我注意到 session ID cookie 总是被发送到服务器。使用该 session ID，我可以获得服务器上的 session 对象，因此我可以“ 获取/设置 session 中的一些状态信息 ”。
这是否打破了 RESTful API 的“无状态代码”？
添加 1
(我的问题的背景如下。)
我尝试通过调用 RESTful API 来验证用户名和密码来实现登录页面。
每次用户尝试访问我网站的页面时，登录 servlet filter将检查 session (这是 getSession() 被调用的地方)让该用户查看是否存在有效的登录信息。如果没有，登录过滤器会将用户重定向到登录页面。
在登录页面上，使用用户名和密码对服务器上的 RESTful API 进行 AJAX 调用。根据 RESTful API 调用的结果，页面上的 JavaScript 将决定是否让用户进入我的站点。
所以，在这种情况下，我不得不使用 session .
详细代码位于此处:
Is this login logic via RESTful call sound?

Answer 1

简单地说:在 REST 应用程序中，每个请求都必须包含服务器理解所需的所有信息，而不是依赖于服务器记住先前的请求。

在服务器上存储 session 状态违反了 REST 架构的无状态约束。因此 session 状态必须完全由客户端处理。

继续阅读以了解更多详情。

session 状态

传统的 Web 应用程序使用远程 session 。在这种方法中，应用程序状态完全保存在服务器上。请参阅 Roy T. Fielding 的以下引述 dissertation :

3.4.6 Remote Session (RS)

The remote session style is a variant of client-server that attempts to minimize the complexity, or maximize the reuse, of the client components rather than the server component. Each client initiates a session on the server and then invokes a series of services on the server, finally exiting the session. Application state is kept entirely on the server. [...]

虽然这种方法带来了一些优势，但它降低了服务器的可扩展性:

The advantages of the remote session style are that it is easier to centrally maintain the interface at the server, reducing concerns about inconsistencies in deployed clients when functionality is extended, and improves efficiency if the interactions make use of extended session context on the server. The disadvantages are that it reduces scalability of the server, due to the stored application state, and reduces visibility of interactions, since a monitor would have to know the complete state of the server.

无状态约束

REST 架构风格是在包括服务器无状态在内的一组约束之上定义的。根据 Fielding 的说法，REST 无状态约束定义如下:

5.1.3 Stateless

[...] each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client. [...]

此约束导致可见性、可靠性和可扩展性的属性:

Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request. Reliability is improved because it eases the task of recovering from partial failures. Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn't have to manage resource usage across requests.

认证和授权

如果客户端请求需要身份验证的 protected 资源，则每个请求都必须包含所有必要的数据才能进行正确的身份验证/授权。请参阅 RFC 7235 中的引用:

HTTP authentication is presumed to be stateless: all of the information necessary to authenticate a request MUST be provided in the request, rather than be dependent on the server remembering prior requests.

并且认证数据应该属于标准 HTTP Authorization 标题。来自 RFC 7235 :

4.2. Authorization

The Authorization header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested. [...]

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

对于身份验证，您可以使用 Basic HTTP Authentication方案，它将凭据作为用户名和密码对传输，使用 Base64 编码:

Authorization: Basic <credentials>

如果您不想在每个请求中发送用户名和密码，可以将用户名和密码交换为在每个请求中发送的 token (例如 JWT )。 JWT 可以包含用户名、到期日期和可能与您的应用程序相关的任何其他元数据:

Authorization: Bearer <token>

您的服务器可能有什么问题

一旦你有了一个 session 标识符，我猜你的应用程序中的某个地方正在创建一个 HTTP session 。它可以在您自己的代码中，也可以在您正在使用的框架的代码中。

在Java应用中，必须保证以下方法是 不是 被调用:

HttpServletRequest#getSession()

HttpServletRequest#getSession(boolean) 与 true