Session 会话真的违反了宁静吗？

在RESTful API中使用会话真的违反了RESTful吗？我已经看到很多观点都朝着这两个方向发展，但我不相信会议是不停的。在我看来：

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

那么会话如何违反这一点呢

• 客户端会话是使用cookie实现的
• Cookie只是一个额外的HTTP头
• 可以随时获取和撤销会话cookie
• 如果需要，会话cookie可以有无限的生存时间
• 会话id（身份验证令牌）在服务器端进行验证

因此，对于客户端来说，会话cookie与任何其他基于HTTP头的身份验证机制完全相同，只是它使用

cookie

头，而不是

Authorization

或某些其他专有头。如果没有连接到cookie值服务器端的会话，为什么会有不同？只要服务器的行为是RESTful的，服务器端实现就不需要关注客户机。因此，Cookie本身不应使API不安，会话对客户端来说只是Cookie

---

我的假设错了吗？是什么让会话cookies不安？

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

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

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

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

我希望这一切都有意义。如果还没有，您还应该查看的。对于REST的信条到底在为什么而争论以及为什么争论，这一点特别有启发性

会议不是无休止的

你是说REST服务只用于http还是我弄错了smth？基于Cookie的会话只能用于自己的（！）基于http的服务！（使用cookie可能会有问题，例如从手机/控制台/桌面等）

如果您为3d party开发者提供RESTful服务，请不要使用基于cookie的会话，而是使用令牌来避免安全问题

---

Cookie不用于身份验证。为什么要重新发明轮子？HTTP具有设计良好的身份验证机制。如果我们使用cookie，我们就会陷入只将HTTP用作传输协议的境地，因此我们需要创建自己的信令系统，例如，告诉用户他们提供了错误的身份验证（使用HTTP 401将是不正确的，因为我们可能不会像HTTP规范要求的那样向客户端提供

Www-Authenticate

）。还应注意的是，

设置Cookie

仅是对客户端的建议。它的内容可以保存，也可以不保存（例如，如果cookie被禁用），而

授权

头会在每次请求时自动发送

另一点是，要获得授权cookie，您可能需要首先在某个地方提供您的凭据？如果是这样的话，那它不是不安吗？简单的例子：

• 您尝试在没有cookie的情况下获取/a
• 你不知怎么得到了授权请求
• 您可以通过某种方式进行授权，比如

  POST/auth

• 您将获得

  设置Cookie

• 您可以尝试使用cookie

  GET/a

  。但是在这种情况下，

  GET/a

  的行为是幂等的吗

总而言之，我相信如果我们访问一些资源，我们需要授权