REST 是无状态的
休息代表代表性状态转移该架构由 Roy Thomas Fielding 在他的论文第五章 https://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm.
Fielding 为 REST 架构定义了一组约束。这些限制之一是无国籍的 https://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3客户端和服务器之间的通信，定义如下（重点内容在他的论文中没有出现）：
5.1.3 无状态 https://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3
[...]从客户端到服务器的每个请求都必须包含理解该请求所需的所有信息，并且不能利用服务器上任何存储的上下文。因此，会话状态完全保留在客户端上。 [...]
所以，如果你保留服务器上的会话状态，你打破了无状态约束 https://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3。因此，这不是休息。在 REST 中，您不会在服务器上有会话，因此，您不会有会话标识符。
每个请求必须包含要处理的所有数据
从客户端到服务器的每个请求都必须包含服务器能够理解的所有必要信息。有了它，您就不再依赖服务器上存储的任何会话上下文。
例如，当访问需要身份验证的受保护资源时，每个请求必须包含正确验证/授权的所有必要数据。这意味着将对每个请求进行身份验证.
看看这句话来自RFC 7235 https://www.rfc-editor.org/rfc/rfc7235#section-5.1.2关于新身份验证方案的考虑因素：
5.1.2.新身份验证方案的注意事项 https://www.rfc-editor.org/rfc/rfc7235#section-5.1.2
HTTP 身份验证框架的某些方面
对新的身份验证方案如何工作施加限制：
- HTTP 身份验证被认为是无状态的：所有
必须提供验证请求所需的信息
在请求中，而不是依赖于服务器的记忆
事先要求。 [...]
并且认证数据（凭证）应该属于标准HTTPAuthorization https://www.rfc-editor.org/rfc/rfc7235#section-4.2标头。来自RFC 7235 https://www.rfc-editor.org/rfc/rfc7235#section-4.2:
4.2.授权 https://www.rfc-editor.org/rfc/rfc7235#section-4.2
The Authorization标头字段允许用户代理进行身份验证
本身有一个原始服务器——通常但不一定是在之后
收到一个401（未经授权）回应。其值包括
包含用户身份验证信息的凭据
所请求资源领域的代理。
Authorization = credentials
[...]
请注意，这个 HTTP 标头的名称很不幸，因为它携带验证数据而不是授权。无论如何，这是发送的标准标头证书.
基于令牌的身份验证
执行基于令牌的身份验证时，令牌就是您的凭据。在这种方法中，您的硬凭证（用户名和密码）将交换为在每个请求中发送的令牌。再次，必须对每个请求进行身份验证，因此您不会利用服务器上任何存储的上下文。
将令牌存储在服务器中的某个位置是完全有效的。并且它不会破坏无状态约束 https://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3REST 架构的一部分。
Tokens
基本上，代币可以是opaque（除了值本身之外，它不透露任何细节，比如随机字符串）或者可以是独立的 (like JSON 网络令牌):
-
随机字符串：可以通过生成随机字符串并将其保存到具有到期日期和与其关联的用户标识符的数据库来颁发令牌。
-
JSON Web 令牌 (JWT): 定义为RFC 7519 https://www.rfc-editor.org/rfc/rfc7519，它是在两方之间安全地表示声明的标准方法。 JWT 是一个独立的令牌，使您能够存储用户标识符、到期日期以及您想要的任何内容（但不存储密码）在有效负载中，这是一个JSON https://en.wikipedia.org/wiki/JSON编码为Base64 https://en.wikipedia.org/wiki/Base64。客户端可以读取有效负载，并且可以通过在服务器上验证其签名来轻松检查令牌的完整性。如果您不需要跟踪 JWT 令牌，则无需保留它们。尽管如此，通过保留令牌，您将有可能使它们失效并撤销它们的访问权限。要查找一些与 JWT 合作的优质资源，请查看http://jwt.io http://jwt.io/.
有许多数据库 http://db-engines.com/en/ranking您可以在其中保留您的令牌。根据您的要求，您可以探索不同的解决方案，例如关系数据库 http://db-engines.com/en/article/Relational+DBMS, 键值存储 http://db-engines.com/en/article/Key-value+Stores or 文件存储 http://db-engines.com/en/article/Document+Stores.
