当我阅读有关 REST 是什么的文档时，他们总是说 REST api 应该是无状态的。在这里，我觉得有点尴尬，因为只是普通的 HTTP 也是无状态的。
既然 REST 可以说它是一种使用 HTTP 协议的特殊架构，那么说 REST 应该是无状态的似乎是多余的。
“无状态”一词在 REST 和 HTTP 中的含义相同吗？ 如果不是，请告诉我区别
我问的不是http中stateless的含义，而是rest和http中stateless的区别
【问题讨论】：
“无状态”一词在 REST 和 HTTP 中的含义相同吗？
是的。
它们相同的原因是 HTTP 是 REST 的结果。
自 1994 年以来，REST 架构风格一直被用于指导现代 Web 架构的设计和开发 -- Fielding, 2000。
在他的论文之前，菲尔丁是RFC 2068 和RFC 2616 的作者。
为了澄清起见，您能否告诉我“现在称为 REST 的原则是通过菲尔丁在 HTTP 上的工作而改进的。”是什么意思？
Reflections on the REST Architectural Style 的第一节包括一个时间线：HTTP 的第一个实现是在 1990-91 年，菲尔丁在 1993 年开始参与。在规范过程中（RFC 1945、RFC 2068、RFC 2616）菲尔丁开发了一个“HTTP 对象模型”后来被理解为“REST 架构风格”。
REST 的第一版是在 1994 年 10 月到 1995 年 8 月之间开发的，主要是作为我们编写 HTTP/1.0 规范和最初的 HTTP/1.1 提案时交流 Web 概念的一种手段。 -- Fielding
也就是说，REST 的思想与 HTTP 的标准化并行发展，以充当预言机：我们如何评估提案是否会损害或破坏 Web 的重要属性？ em>
Section 6.3.4 of the thesis 描述了一些标准化不匹配的后果。
【讨论】：
HTTP 术语中的无状态意味着每个请求都不知道任何先前的请求，即 HTTP 中没有内置机制来跟踪谁发出请求以及这些请求的影响。
就 RESTful 服务而言，这意味着每个请求不依赖状态（例如，保存的客户端信息）来完成请求——完成请求所需的所有信息都包含在请求消息中（CRUD 操作、有问题的资源、身份验证令牌、应用平台标识等）。
这意味着您的 RESTful API 应该由管理身份验证、会话管理和其他非 RESTful 操作的分层架构保护。
在这种情况下，RESTful 服务和 HTTP 都应该在相同的约束条件下运行：无状态（如上定义）。
设计这样的 REST API 似乎很直观，但您会惊讶于在许多 REST 服务的核心中发现的紧密耦合：
GET /users/:id
if authenticated and authorized //not stateless
send User resource
为了解决这个问题，大多数 HTTP 框架都提供了中间件层。
有用的 REST 设计问题：
【讨论】：
REST 代表 Representational State Transfer，这意味着状态是具象的。 api 服务器上不保留请求跟踪机制或会话。请求的状态可能会转移到其他 api 服务器。
此外，像 GET /users/:id 这样的约定规定每个资源都有一个内置在 url 中的标识机制，因此不需要跟踪请求中的资源，因为 URL 本身包含客户端资源请求信息，例如：获取 /users/1，放置 /users/1。
【讨论】：