我编写了一个RESTful servlet，UI开发人员想要在服务器上保存登录状态。
他提出了这个奇怪的说法：“我没有遇到过纯REST的生产REST实现。我看到的所有实现都让服务器维护会话。”
我发现这很难接受。首先是技术性，那里有很多普通的HTTP页面，都是纯粹的RESTful。其次，是的，有非RESTful实现标记为RESTful，就像黄铜标记为“黄金”一样。第三，仅仅因为其他人从桥上跳下来并不意味着我应该这样做。
背景：这是一个使用HTTPS和基本身份验证的JavaScript Ajax Web应用程序。为避免通常（不可自定义的）浏览器登录弹出框，应用程序会显示一个登录屏幕，其中包含产品徽标和名称和密码的文本框。名称和密码存储在文档中，并在每个请求的Authorization标头中发送。如果刷新页面，则名称和密码将丢失，用户必须再次输入。这被认为是一个错误; UI开发人员希望能够在不再提供密码的情况下按下刷新按钮。
因此开发人员想要使用cookie或JSP会话。 Abby，最终每个REST实现都在服务器上维护应用程序状态吗？或者有没有办法解决这个问题，仍然保持我的RESTful纯度？
答案 0 :(得分：3)
我认为出于实际原因（主要是可浏览的功能），您需要区分应用程序状态和身份验证状态。我想不出任何在服务器端没有保留某种形式状态的认证机制。
真正重要的是它与应用程序的脱钩程度。例如，HTTP Digest在服务器上保留某种形式的状态，但这显然是作为正常WWW-Authenticate和Authorization标头协商的一部分抽象出来的。由于大多数浏览器本身都支持它，因此它与应用程序正交，因此不会破坏REST的无状态原则。
如今，由于用户对浏览器中不满足HTTP Basic / Digest身份验证的美学期望，网站倾向于使用基于表单的身份验证和随后的Cookie。公平地说，它不仅仅是它的外观，它还是一个可用性问题（例如“忘记了你的密码”信息，尽管这可能是401响应的主体）和安全性。浏览器不允许您轻松地从基本/摘要/证书身份验证中注销，除非您在一个页面中完全在Ajax中完成，如您所述，这可以帮助CSRF。
我认为cookie可用于身份验证，但请确保您不在会话中存储与应用程序相关的变量。
您可以阅读一些Roy Fielding's comments on the topic：
身份验证是正交的。饼干 它们也是正交的 仅用于内容协商或 认证。但是，Cookie REST中不允许进行身份验证 因为它缺乏可见性 导致安全问题，因为 其他组件不知道它是什么 敏感信息。
编辑（关于安全方面的进一步评论）：
我意识到Roy Fielding在我引用的消息中的评论是出于安全原因而反对cookie。他是对的。但是，在我看来，通过Basic / Digest / Cert（2003年没有真正关注，消息发布日期）比反对cookie盗窃更难保护CSRF。这取决于当然的实施。没有完美的解决方案，但如果您使用cookie，请通过HTTPS使用安全cookie。
答案 1 :(得分：2)
我认为使用cookie在客户端维护此信息没有问题。 Cookie只有在用作某些服务器端会话状态的指针时才会成为问题。
您必须关注的主要问题是cookie中信息的安全性。您可能不希望将明文密码放在cookie中： - ）
答案 2 :(得分：0)
此致
阿比。
答案 3 :(得分：0)
如果您在身份验证后返回某种会话ID并将其与每次调用一起传入，这与每次调用传递身份验证凭据没有多大区别。在性能方面，后者仍然可以缓存凭据，因此没有性能损失。在安全性方面，不必保持凭据更好，因为会话到期但凭证（通常）不会。可以说，避免会话更加健壮，因为服务器可以忘记呼叫之间的所有内容但仍然有效。
简而言之，在任何一个方向上都没有绝对强烈的争论，你可能不应该对你是否对你的REST承诺充分“纯粹”感到不满。真正的问题是客户的行为，正如Sjoerd建议的那样，你可以独立调整这一点。