以RESTful方式验证网页用户的首选方法是什么？

Question

我正在开发一个新的实验性Web应用程序框架,我决定给RESTful一些关注.我已经阅读了基础知识,并且觉得我对RESTful作为一个概念非常了解.

我已经启动并运行了一个系统,严格使用URL来定义系统中的"名词",并从HTTP请求方法中获取"动词".我正在使用javascript ajax调用来提供对HTML表单无法提供的DELETE和PUT方法的访问.(我意识到这些措施并非严格要求是RESTful,但它满足'统一接口'的要求).

问题在于无状态和可缓存性与身份验证.用于网站上的用户认证的标准模型涉及"登录"认证事件,之后(如果成功)用户具有持久安全会话的"在墙内",并且可以在未经认证的用户可能没有的后续请求上查看和执行操作.这种身份验证的持久性似乎打破了RESTful-ness.缓存和无状态似乎被破坏,因为经过身份验证的用户可能会看到与未经身份验证的用户将针对同一请求看到的HTML不同的HTML(例如,在边栏中可能有一个登录表单用于记录 - 用户).

使用www-authenticate策略仅对需要身份验证的请求对用户进行身份验证似乎是朝着正确方向迈出的一步,因为它不涉及持久安全会话的概念.然而,仍然存在如何向最终用户描绘"登录"外观以保持我们对网站的期望.

那么在目前的想法中,以严格的REST方式处理网页的身份验证和权限的首选方法是什么,同时仍允许HTML中的登录装饰？

Answer 1

这种身份验证的持久性似乎破坏了 RESTful 性

您可能会考虑创建一个会话，而不是对用户进行身份验证。您将收到一个新的“会话 ID”以及相应的 HTTP 状态代码（200：正常、403：禁止等）。

对于同一请求，用户可能会看到与未经身份验证的用户看到的 HTML 不同的 HTML

您将询问您的 REST 服务器：“您能为我获取此会话 ID 的 HTML（或任何资源）吗？”。HTML 将根据“会话 ID”而有所不同。

通过这种方法，“持久安全会话”就不再存在障碍。您只是在执行会话。

如果您选择此方法，名词（或资源）将代表实际会话。