0

我正在为我的应用程序构建一个 RESTful API。很少有服务是公开的，其余的都需要身份验证和授权。

需要明确的是，我的问题不是关于验证 Web 服务。我已经决定发送带有服务器提供的访问令牌的 HTTP 标头。其原因包括：

  • 创建一个可以跟踪用户活动的“会话”
  • 在 XXX 不活动后超时访问令牌
  • 跟踪每个“会话”的用户行为模式

到目前为止，这种方法运行良好。我对提供“登录”服务的任何设计指南感兴趣。我不想只对请求进行身份验证，但我想针对“会话”跟踪 Web 服务的使用情况。

除了“会话”跟踪之外，我们还有一些要求，要求我们跟踪失败的登录尝试并在 XXX 次失败尝试后采取适当的措施，以及密码过期和授权前的电子邮件地址验证等。

具体来说，我关心为此设计 URI 的最佳方式。一种选择是：

/api/authentication/login?username=UN&password=PW

这可以返回要在标头中用于安全服务调用的访问令牌。这是一个好方法吗？有更好的方法吗？是否有更好的模式用于命名 URI？

我最大的问题是 URI 并不纯粹坚持“URI 应该代表资源”的方法。结束结束可能没什么大不了的，但我想知道是否有更好的方法。

谢谢！

4

1 回答 1

0

通常，RESTful API 喜欢无状态。这意味着 API 本身并不关心保持会话，也不关心。

您所做的是验证 1 次，然后获得一个临时密钥。该密钥最终不再有用，因为密钥中包含有关何时到期的信息。

此外，由于这些大型 API 是基于消息队列构建的，它们知道每个操作的时间戳。他们基本上可以跟踪活动。

因此，在 RESTful API 设计中，您经常会遇到 URL 中有资源的场景，然后需要设置各种额外的东西。

一个好的经验法则是将复杂性隐藏在?. 这种哲学的一个典型用例是您在获取/some/resource. 这有什么关系？好吧，如果你记得偶尔用其他东西装饰你的基于资源的 API 并不是一种致命的罪过，那么当你觉得足智多谋可能存在问题时，你可以类似地对待其他场景，但本质上你仍然有需要的 RPC-ish 端点存在以使您的 API 完全满足您的需求。或者，当然，您可以任意设置某些 HTTP 动词来等同于这些东西。

如果您想使用附加功能扩展您的资源，请尝试在调用的基本 url 中坚持资源结构，然后根据您的一次性需求进行装饰。

Resource: /api/authentication
With modifier: /api/authentication/login
With data: /api/authentication/login?username=UN&password=PW

也不是那么坏。但同样，如果你想完全放松，你可以这样说（这纯粹是猜想，这些事情你需要自己决定）：

Get logged in status - GET - /api/authentication/:id
Create / Update logged in status - POST / PUT - /api/authentication(/:id)
Log out - DELETE - /api/authentication/:id

...或者您可以省略:id路由，只是将该信息隐藏在附加到调用的数据主体中，也就是隐藏复杂性

于 2013-09-18T22:24:59.880 回答