我正在创建一个REST api，密切关注apigee建议，使用名词不是动词，api版本加入url，每个集合有两个api路径，GET POST PUT DELETE使用等等。
我正在使用登录系统，但不确定正确的REST登录方式。我现在不是在处理安全问题，只是登录模式或流程。 （稍后我们将添加2步oAuth，HMAC等）
可能的选项
https://api...com/v1/login.json https://api...com/v1/users.json 登录用户的正确REST样式是什么？
答案 0 :(得分：127)
Principled Design of the Modern Web Architecture by Roy T. Fielding and Richard N. Taylor，即所有REST术语的作品序列来自，包含客户端 - 服务器交互的定义：
所有REST互动都是 无状态 。也就是说，每个 请求都包含 连接器理解所需的所有信息 请求，独立于之前可能有的任何请求 。
这个限制完成了四个功能，第一个和第三个在这个特殊情况下很重要：
现在让我们回到您的安全案例。每个请求都应包含所有必需的信息，授权/身份验证也不例外。怎么做到这一点？每次请求都可以通过电汇直接发送所有必需的信息。
如何实现这一目标的一个例子是hash-based message authentication code or HMAC。实际上，这意味着向每个请求添加当前消息的哈希码。由加密哈希函数与秘密加密密钥组合计算的哈希代码。 加密哈希函数是预定义的，或者是按需代码 REST概念的一部分（例如JavaScript）。 秘密加密密钥应由服务器作为资源提供给客户端，客户端使用它来计算每个请求的哈希码。
有很多 HMAC 实施的例子，但我希望你注意以下三点：
如果客户端知道密钥，那么它就可以使用资源进行操作了。否则，他将被临时重定向（状态码307临时重定向）以授权并获取密钥，然后重定向回原始资源。在这种情况下，无需预先知道（即某处的硬编码）授权客户端的URL是什么，并且可以随着时间调整此模式。
希望这会帮助您找到合适的解决方案！
答案 1 :(得分：41)
TL; DR 登录每个请求不是实现API安全性所必需的组件，身份验证是。
在不谈论安全性的情况下，很难回答关于登录的问题。使用一些身份验证方案，没有传统的登录方式。
REST并未规定任何安全规则，但实际上最常见的实现是具有3向身份验证的OAuth（正如您在问题中提到的那样）。本身没有登录，至少没有每个API请求。使用3向身份验证，您只需使用令牌。
此方案为用户提供随时撤消访问权限的选项。实际上，我见过的所有公开可用的RESTful API都使用OAuth来实现它。
我认为你不应该在登录方面构建你的问题（和问题），而是考虑一般地保护API。
有关REST API身份验证的更多信息，您可以查看以下资源：
答案 2 :(得分：24)
REST理念的一个重要部分是在设计API时尽可能多地利用HTTP协议的标准功能。将该理念应用于身份验证，客户端和服务器将利用API中的标准HTTP身份验证功能。
登录屏幕非常适合人类用户使用案例：访问登录屏幕，提供用户/密码，设置cookie，客户端在将来的所有请求中提供该cookie。不能指望使用Web浏览器的人为每个单独的HTTP请求提供用户ID和密码。
但是对于REST API，登录屏幕和会话cookie并不是绝对必要的，因为每个请求都可以包含凭据而不会影响人类用户;如果客户在任何时间不合作，可以给出401“未经授权”的响应。 RFC 2617描述了HTTP中的身份验证支持。
TLS（HTTPS）也是一个选项，它将允许通过验证另一方的公钥，在每个请求中对客户端进行服务器身份验证（反之亦然）。此外，这可以确保渠道获得奖金。当然，在通信之前进行密钥对交换是必要的。 （注意，这具体是关于使用TLS识别/验证用户。使用TLS / Diffie-Hellman保护频道总是一个好主意，即使您没有通过其公钥识别用户。）
示例：假设OAuth令牌是您的完整登录凭据。一旦客户端具有OAuth令牌，就可以在每个请求的标准HTTP身份验证中将其作为用户ID提供。服务器可以在首次使用时验证令牌，并将检查结果与生存时间一起缓存，每次请求都会更新。如果没有提供，任何要求身份验证的请求都会返回401。