在 REST 应用程序中维护会话的方法答案

【问题标题】：Way to maintain a session in a REST application在 REST 应用程序中维护会话的方法
【发布时间】：2010-03-23 19:07:33
【问题描述】：

我们有一个 REST 应用程序，主要由不需要维护其状态的应用程序使用，所以到目前为止，我们一直保持安静的“RESTFUL”，无需维护状态。我们使用 Private/Public（类似于 Amazon）进行身份验证。目前客户端为每个请求传递凭据

现在我们有一个新要求，我们必须维护状态（或对话）。客户端可以是富应用程序或手持设备。我正在尝试提出实现状态的最佳方法。我们应该传递会话 ID 并维护该 ID ..这是最好的也是唯一的解决方案吗？

【问题讨论】：

为什么 RIA 或手持设备不能保持会话并从您的 REST 服务器获取资源？为什么要打破 REST 的核心规则？为什么不将有状态会话推送到它所属的位置——在人机界面中？
好问题，您是否可以通过每个请求发送凭据然后进行身份验证..这似乎是我团队中一些人的关键
身份验证可以很容易地被缓存在服务器端并造成几乎为零的性能损失。
@romanianGeek 这就是授权标头的使用方式。每个 http 请求都应该独立存在。如果您正在请求需要授权的资源，请发送它。
@Gandalf “缓存服务器端”是什么意思？如果您在服务器端“缓存”与特定客户端相关的某些内容，那么您实际上是在保持会话状态。如何将客户端请求与服务器上缓存的信息进行匹配。

标签： rest

【解决方案1】：

传递会话 ID 不是保持会话状态的唯一方法，也不是最佳方法。如果您有 RIA，最好的方法是维护客户端本身的状态，它所属的位置，正如一些 cmets 所建议的那样。这意味着仍然会在每个请求中发送凭据。

对每个请求重新进行身份验证是唯一的方法，如果您觉得服务器的性能受到影响，服务器可以（如建议的那样）缓存身份验证请求的结果一段的时间。 Digest authentication 可以通过加密签名通过网络传输的令牌来帮助避免缓存响应。

如果这还不够好，您可以使用类似于 Google ClientLogin 的东西，并为客户端提供加密令牌，无需请求授权即可验证，也无需通过网络传递用户的真实凭据。通过 https 登录，然后通过 http 使用生成的令牌来谷歌自己。它在令牌的生命周期内对重放攻击开放。

【讨论】：