小编典典

REST API 登录模式

all

我正在创建一个 REST api,密切遵循 apigee 建议,使用名词而不是动词,在 url 中烘焙的 api 版本,每个集合两个 api 路径,GET
POST PUT DELETE 用法等。

我正在开发登录系统,但不确定登录用户的正确 REST 方式。我目前不在安全方面工作,只是登录模式或流程。(稍后我们将添加 2 步 oAuth,使用 HMAC
等)

可能的选项

  • 一个类似的帖子 https://api...com/v1/login.json
  • 一个 PUT 到类似的东西https://api...com/v1/users.json
  • 我没有想到的东西......

登录用户的正确 REST 样式是什么?


阅读 61

收藏
2022-07-09

共1个答案

小编典典

Roy T. Fielding 和 Richard N. Taylor 的现代 Web
架构的原则设计
,即来自所有
REST 术语的作品序列,包含客户端-服务器交互的定义:

所有 REST 交互都是 _ 无状态 的。也就是说,每个 _ 请求都包含连接器理解请求所需的所有信息,与之前可能出现的任何请求无关

这个限制完成了四个功能,第一个和第三个在这种特殊情况下很重要:

  • 第一 :它 消除了连接器在请求之间保留应用程序状态的任何需要 ,从而减少了物理资源的消耗并提高了可扩展性;
  • 第三 :它允许中介单独查看和 理解请求 ,这在动态重新排列服务时可能是必要的;

现在让我们回到您的安全案例。每个请求都应包含所有必需的信息,授权/身份验证也不例外。如何做到这一点?从字面上看,每次请求都会通过电线发送所有必需的信息。

如何存档的示例之一是 基于哈希的消息身份验证代码HMAC 。在实践中,这意味着向每个请求添加当前消息的哈希码。 由密码散列函数 结合
秘密密钥 计算的散列码。 加密哈希函数 要么是预定义的,要么是 按需代码 REST 概念的一部分(例如 JavaScript)。 秘密密钥
应该由服务器作为资源提供给客户端,客户端使用它来计算每个请求的哈希码。

在实践中如何运作

如果客户端知道密钥,那么它就可以使用资源进行操作了。否则他会被临时重定向(状态码307 Temporary
Redirect)授权并获取秘钥,然后重定向回原来的资源。在这种情况下, 无需事先知道(即在某处硬编码)授权客户端的 URL 是什么
,并且可以随时间调整此模式。

希望这将帮助您找到正确的解决方案!

2022-07-09