会话真的违反了 RESTfulness 吗？

首先，REST 不是一种宗教，不应该这样对待。尽管 RESTful 服务有很多优点，但您应该只遵循 REST 的原则，只要它们对您的应用程序有意义。

也就是说，身份验证和客户端状态不违反 REST 原则。虽然 REST 要求状态转换是无状态的，但这是指服务器本身。从本质上讲，所有 REST 都是关于文档的。无状态背后的想法是服务器是无状态的，而不是客户端。任何发出相同请求（相同的标头、cookie、URI 等）的客户端都应该被带到应用程序中的相同位置。如果网站存储了用户的当前位置并通过更新此服务器端导航变量来管理导航，那么将违反 REST。根据服务器端的状态，具有相同请求信息的另一个客户端将被带到不同的位置。

Google 的 Web 服务是 RESTful 系统的绝佳示例。它们需要一个带有用户身份验证密钥的身份验证标头，以便在每个请求时传递。这确实稍微违反了 REST 原则，因为服务器正在跟踪身份验证密钥的状态。必须维护此密钥的状态，并且它具有某种到期日期/时间，在此之后它不再授予访问权限。然而，正如我在帖子顶部提到的，必须做出牺牲才能让应用程序真正工作。也就是说，身份验证令牌的存储方式必须允许所有可能的客户端在其有效时间内继续授予访问权限。如果一台服务器正在管理身份验证密钥的状态，以至于另一台负载平衡服务器无法接管基于该密钥的请求，那么您已经开始真正违反 REST 的原则。 Google 的服务可确保您在任何时候都可以将您在手机上使用的身份验证令牌用于负载平衡服务器 A，并从您的桌面访问负载平衡服务器 B，并且仍然可以访问系统并被定向到相同的资源，如果请求是相同的。

归根结底，您需要确保您的身份验证令牌已针对某种类型的后备存储（数据库、缓存等）进行验证，以确保您保留尽可能多的 REST 属性。

我希望所有这些都是有道理的。如果您还没有查看 wikipedia article on Representational State Transfer 的 Constraints section，您还应该查看。关于 REST 的原则实际上在争论什么以及为什么争论，这尤其具有启发性。

---

首先，让我们定义一些术语：

RESTful：可以将符合本节中描述的 REST 约束的应用程序描述为“RESTful”。 [15]如果服务违反了任何必需的约束，则不能将其视为 RESTful。根据维基百科。

无状态约束：我们接下来为客户端-服务器交互添加一个约束：通信本质上必须是无状态的，如第 3.4.3 节（图 5-3）的客户端-无状态-服务器（CSS）样式中，这样每个请求从客户端到服务器必须包含理解请求所需的所有信息，并且不能利用服务器上存储的任何上下文。因此，会话状态完全保留在客户端上。根据菲尔丁论文。

因此，服务器端会话违反了 REST 的无状态约束，因此 RESTful 也是如此。

因此，对于客户端而言，会话 cookie 与任何其他基于 HTTP 标头的身份验证机制完全相同，只是它使用 Cookie 标头而不是 Authorization 或其他一些专有标头。

通过会话 cookie，您将客户端状态存储在服务器上，因此您的请求具有上下文。让我们尝试将负载均衡器和另一个服务实例添加到您的系统。在这种情况下，您必须在服务实例之间共享会话。很难维护和扩展这样的系统，所以它的扩展性很差......

在我看来，cookie 没有任何问题。 cookie 技术是一种客户端存储机制，其中存储的数据通过每个请求自动附加到 cookie 标头。我不知道这种技术存在问题的 REST 约束。所以技术本身没有问题，问题在于它的使用。 Fielding wrote a sub-section 关于他认为 HTTP cookie 不好的原因。

从我的角度来看：RESTful 不禁止身份验证（否则在 RESTful 服务中几乎没有用处）身份验证是通过在请求中发送身份验证令牌来完成的，通常需要以某种方式获取此身份验证令牌的标头，并且可能是已撤销，在这种情况下需要更新身份验证令牌需要由服务器验证（否则它不会是身份验证）

你的观点很中肯。唯一的问题是在服务器上创建身份验证令牌的概念。你不需要那部分。您需要将用户名和密码存储在客户端上，并随每个请求一起发送。除了 HTTP 基本身份验证和加密连接之外，您不需要做更多的事情：

https://i.stack.imgur.com/9kiTW.png

图 1. - 受信任客户端的无状态身份验证

您可能需要在服务器端使用内存中的身份验证缓存来加快速度，因为您必须对每个请求进行身份验证。

现在，您编写的受信任的客户可以很好地工作，但是第 3 方客户呢？他们不能拥有用户名和密码以及用户的所有权限。因此，您必须单独存储特定用户可以拥有的 3rd 方客户端的权限。因此客户端开发者可以注册他们的第 3 方客户端，并获得一个唯一的 API 密钥，并且用户可以允许第 3 方客户端访问他们的部分权限。比如读取姓名和电子邮件地址，或者列出他们的朋友等等……在允许第三方客户端之后，服务器将生成一个访问令牌。第三方客户端可以使用这些访问令牌来访问用户授予的权限，如下所示：

https://i.stack.imgur.com/HeG0r.png

图 2. - 第三方客户端的无状态身份验证

因此，第 3 方客户端可以从受信任的客户端（或直接从用户）获取访问令牌。之后，它可以使用 API 密钥和访问令牌发送有效请求。这是最基本的 3rd 方身份验证机制。您可以在每个 3rd 方身份验证系统（例如 OAuth）的文档中阅读有关实施细节的更多信息。当然，这可能更复杂，更安全，例如您可以在服务器端签署每个请求的详细信息，然后将签名与请求一起发送，等等......实际的解决方案取决于您的应用程序的需要。

---

Cookie 不用于身份验证。为什么要重新发明轮子？ HTTP 具有精心设计的身份验证机制。如果我们使用 cookie，我们就会陷入只使用 HTTP 作为传输协议，因此我们需要创建自己的自己的信号系统，例如，告诉用户他们提供了错误的身份验证（使用 HTTP 401 会不正确，因为我们可能不会向客户端提供 Www-Authenticate，因为 HTTP 规范要求 :) )。还应该注意的是，Set-Cookie 只是对客户的建议。它的内容可能会被保存，也可能不会被保存（例如，如果 cookie 被禁用），而 Authorization 标头会在每次请求时自动发送。

另一点是，要获得授权 cookie，您可能想先在某处提供您的凭据？如果是这样，那不是 RESTless 吗？简单的例子：

你尝试 GET /a 没有 cookie

您以某种方式收到授权请求

你去以某种方式授权，比如 POST /auth

你得到 Set-Cookie

您尝试 GET /a 与 cookie。但是在这种情况下 GET /a 是否具有幂等性？

总而言之，我相信如果我们访问某个资源并且我们需要进行身份验证，那么我们必须在同一资源上进行身份验证，而不是在其他任何地方进行身份验证。

---

实际上，RESTful 仅适用于 RESOURCES，如通用资源标识符所示。因此，甚至谈论关于 REST 的标头、cookie 等内容是不合适的。 REST 可以在任何协议上工作，即使它恰好是通过 HTTP 常规完成的。

主要决定因素是这样的：如果您发送一个 REST 调用，它是一个 URI，那么一旦调用成功到达服务器，该 URI 是否返回相同的内容，假设没有执行转换（PUT、POST、DELETE） ?此测试将排除错误或返回的身份验证请求，因为在这种情况下，请求尚未到达服务器，这意味着将返回与给定 URI 对应的文档的 servlet 或应用程序。

同样，在 POST 或 PUT 的情况下，您是否可以发送给定的 URI/payload，并且无论您发送多少次消息，它总是会更新相同的数据，以便后续 GET 将返回一致的结果？

REST 是关于应用程序数据的，而不是关于传输该数据所需的低级信息。

在下面的博客文章中，Roy Fielding 对整个 REST 理念进行了很好的总结：

http://groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/5841

“一个 RESTful 系统从一个稳态发展到下一个稳态，每个这样的稳态既是一个潜在的开始状态，也是一个潜在的结束状态。也就是说，一个 RESTful 系统是未知数量的组件，它们服从一组简单的规则使得它们总是处于 REST 状态或从一个 RESTful 状态转换到另一个 RESTful 状态。每个状态都可以通过它包含的表示和它提供的一组转换来完全理解，并且转换限制为统一的一组动作是可以理解的。系统可能是一个复杂的状态图，但每个用户代理一次只能看到一个状态（当前稳态），因此每个状态都很简单，可以独立分析。用户 OTOH 可以随时创建自己的转换（例如，输入 URL、选择书签、打开编辑器等）。”

转到身份验证问题，无论是通过 cookie 还是 headers 来完成，只要信息不是 URI 和 POST 有效负载的一部分，它就与 REST 完全无关。因此，关于无状态，我们只讨论应用程序数据。

例如，当用户在 GUI 屏幕中输入数据时，客户端会跟踪已输入的字段、未输入的字段、缺少的任何必填字段等。这都是 CLIENT CONTEXT，不应发送或跟踪由服务器。发送到服务器的是需要在 IDENTIFIED 资源中修改的完整字段集（通过 URI），以便在该资源中发生从一种 RESTful 状态到另一种状态的转换。

因此，客户端会跟踪用户正在做什么，并且只会将逻辑上完整的状态转换发送到服务器。

---

HTTP事务，基本访问认证，不适合RBAC，因为基本访问认证每次都使用加密后的username:password来识别，而RBAC中需要的是用户想要用于特定调用的角色。 RBAC 不会验证用户名的权限，而是验证角色的权限。

您可以像这样尝试连接：usernameRole:password，但这是不好的做法，而且效率也很低，因为当用户拥有更多角色时，身份验证引擎需要测试连接中的所有角色，并且每次调用都需要再次测试。这将破坏 RBAC 的最大技术优势之一，即非常快速的授权测试。

因此，使用基本访问身份验证无法解决该问题。

为了解决这个问题，会话维护是必要的，根据一些答案，这似乎与 REST 相矛盾。

这就是我喜欢 REST 不应被视为一种宗教的答案。在复杂的业务案例中，例如在医疗保健领域，RBAC 绝对是常见且必要的。如果不允许他们使用 REST，那就太可惜了，因为所有 REST 工具的设计者都将 REST 视为一种宗教。

对我来说，通过 HTTP 维护会话的方法并不多。可以使用带有 sessionId 的 cookie 或带有 sessionId 的标头。

如果有人有其他想法，我会很高兴听到它。

---

据我了解，当我们谈论会话时，有两种状态

客户端和服务器交互状态

资源状态

这里的无状态约束是指Rest中的第二种类型。使用 cookie（或本地存储）不会违反 Rest，因为它与第一个有关。

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

这里的问题是，要在服务器上完成的每个请求都需要来自客户端的所有必要数据。那么这被认为是无状态的。再说一次，我们在这里不是在谈论 cookie，而是在谈论资源。

---

我认为令牌必须包含其中编码的所有需要的信息，这通过验证令牌和解码信息来进行身份验证https://www.oauth.com/oauth2-servers/access-tokens/self-encoded-access-tokens/

---

不，使用会话不一定违反 RESTful。如果您遵守 REST 规则和约束，那么使用会话（维护状态）将是多余的。毕竟，RESTful 要求服务器不维护状态。

---

会话不是 RESTless 您的意思是 REST 服务仅用于 http 还是我弄错了？基于 Cookie 的会话只能用于自己的（！）基于 http 的服务！ （使用 cookie 可能会出现问题，例如来自 Mobile/Console/Desktop/etc。）如果您为 3d 方开发人员提供 RESTful 服务，请不要使用基于 cookie 的会话，而是使用令牌来避免安全问题。

---