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