session - session 真的违反了 RESTful 原则吗？

Question

在 RESTful API 中使用 session 真的违反了 RESTful 原则吗？我见过很多不同方向的观点，但我不相信 session 是RESTless。从我的角度来看:

• RESTful 并不禁止身份验证(否则在 RESTful 服务中几乎没有用处)
• 身份验证是通过在请求中发送身份验证 token (通常是 header )来完成的
• 需要以某种方式获取此身份验证 token ，并且可能会被撤销，在这种情况下需要更新
• 身份验证 token 需要经过服务器验证(否则就不是身份验证)

那么 session 是如何违反这一点的呢？

• 客户端， session 是使用cookie实现的
• cookie 只是一个额外的 HTTP header
• 可以随时获取和撤销 session cookie
• 如果需要， session cookie 可以具有无限的生命周期
• session ID(身份验证 token )已在服务器端进行验证

因此，对于客户端来说， session ​​ Cookie 与任何其他基于 HTTP header 的身份验证机制完全相同，只是它使用 Cookie header 而不是 Authorization 或其他一些专有 header 。如果服务器端没有附加到 cookie 值的 session ，为什么会产生影响呢？只要服务器表现 RESTful，服务器端实现就不需要关心客户端。因此，cookie 本身不应该使 API RESTless，而 session 只是客户端的 cookie。

我的假设是错误的吗？是什么让 session cookie RESTless？

Answer 1

首先，REST 不是宗教，不应该被视为宗教。虽然 RESTful 服务有很多优点，但您应该只遵循 REST 的原则，只要它们对您的应用程序有意义。

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

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

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

我希望这一切都是有道理的。您还应该查看Constraints section wikipedia article on Representational State Transfer的如果你还没有。对于 REST 原则的实际主张及其原因，它特别具有启发性。