你早些时候已经在this question上写过这个观察和问题，但后来才注意到这是一个古老而“死”的问题。由于我非常喜欢其他人的一些见解，我将其作为一个新问题重新发布。
对于如何进行RESTful身份验证的问题，人们通常会热情地喊出“HTTP身份验证”。但是，我很怀疑这些人是否曾尝试使用REST制作基于浏览器的应用程序（而不是机器到机器的Web服务）。 （没有违法行为 - 我只是认为他们没有遇到过并发症）
在生成可在浏览器中查看的HTML页面的RESTful服务上使用HTTP身份验证时发现的问题是：
一篇非常富有洞察力的文章逐点解决这些问题here，但这会导致浏览器特定的javascript hackery lot ，解决方法的变通方法等等。因此，它也不是向前兼容的，因此在发布新浏览器时需要不断维护。我不认为这个干净清晰的设计，而且我觉得这是一项额外的工作和头痛，所以我可以热情地向我的朋友们展示我的REST徽章。
我相信cookie是解决方案。但等等，饼干是邪恶的，不是吗？不，他们不是，饼干的使用方式往往是邪恶的。 Cookie本身只是一条客户端信息，就像浏览器在浏览时会跟踪的HTTP身份验证信息一样。这条客户端信息在每次请求时都会发送到服务器，就像HTTP身份验证信息一样。从概念上讲，唯一的区别是这个客户端状态的内容可以由服务器确定，作为其响应的一部分。
通过仅使用以下规则使会话成为RESTful资源：
现在，与HTTP身份验证的唯一区别在于，身份验证密钥由服务器生成并发送给不断发送回来的客户端，而不是客户端从输入的凭据计算它。
我认为这是一个运行良好的充分解决方案，但我必须承认，我不足以识别此方案中的潜在漏洞 - 我所知道的是数百个非RESTful Web应用程序使用本质上是相同的登录协议（$ _SESSION inphp，j2ee中的HttpSession等）。 cookie头内容仅用于寻址服务器端资源，就像接受语言可能用于访问翻译资源一样，等等。我觉得它是一样的，但也许其他人不一样？伙计们，你觉得怎么样？
答案 0 :(得分：4)
一个有趣的问题。我现在正在完成一个REST API实现 - 使用了mod_rewrite和PHP。它在HTTPS上使用HTTP基本身份验证。到目前为止，我们正在开发Palm Pre客户端。开发该客户端的人有点不得不跟踪每个请求提交的用户凭据。
将SESSION作为资源公开的想法很有意思。包括它仍然会违反严格的RESTful原则。即使您将SESSION公开为资源，您仍然可以使用服务器来跟踪客户端状态。严格遵守REST可能需要使用cookie，因为这是浏览器可用的客户端持久性内存。问题是，如果您不希望用户与浏览器实现的HTTP凭据收集进行交互，您可以创建一个JavaScript（或FLash？）客户端来管理客户端的HTTP请求。
我发现有用的一个工具是用于Firefox工具的REST客户端......但即使我正在使用它，我仍然会将我的凭据输入标准浏览器弹出窗口。
我必须承认在我的实施中包含一些黑客。如果您所做的只是使用会话来允许潜在开发人员测试/浏览API，或者我不认为使用基于会话的身份验证是如此重要。纯粹主义者不同意我确定。真的，这归结为......这本质上是一个学术论点。在现实生活中，你必须做有效的工作。
...在10/23/2012添加到此...
RESTful方法坚持让客户跟踪自己的状态不仅仅是学术上的。它对可伸缩性和暴露资源的可寻址性具有重要意义。当我这样说时，我假设通过客户端状态，我们讨论的是特定于请求用户的属性，这些属性会影响RESTful接口发出的响应。 REST的优势之一是它的可寻址性。当您以任何方式做出响应时，依赖于未在请求中传递的信息，您就会开始削减它。只是一个事后的想法... 3年后，哈哈。
答案 1 :(得分：1)
我知道这是一个古老的问题，但我认为这里的很多问题已经在不同的领域得到了解决。特别是，我认为OAuth 2.0 Protocol一直在考虑很多这些问题;我觉得这里没有足够的权威性来提供他们的答案摘要，但链接的网站有很多不同的用例明确地被调出，这对于这个问题似乎非常有用，即使完全没有必要使用完整的OAuth 2.0这里。