我正在创建一个 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 样式是什么？
Roy T. Fielding 和 Richard N. Taylor 的现代 Web 架构的原则设计，即来自所有 REST 术语的一系列作品，包含客户端-服务器交互的定义：
所有 REST 交互都是无状态的。也就是说，每个请求都包含连接器理解请求所需的所有信息，与之前可能出现的任何请求无关。
这个限制完成了四个功能，第一个和第三个在这种特殊情况下很重要：
现在让我们回到您的安全案例。每个请求都应包含所有必需的信息，授权/身份验证也不例外。如何做到这一点？从字面上看，每次请求都会通过电线发送所有必需的信息。
如何存档的示例之一是基于哈希的消息身份验证代码或HMAC。在实践中，这意味着向每个请求添加当前消息的哈希码。由密码散列函数结合秘密密钥计算的散列码。加密哈希函数要么是预定义的，要么是按需代码REST 概念的一部分（例如 JavaScript）。秘密密钥 应该由服务器作为资源提供给客户端，客户端使用它来计算每个请求的哈希码。
HMAC实现的例子有很多，但我希望你注意以下三个：
如果客户端知道密钥，那么它就可以使用资源进行操作了。否则他会被临时重定向（状态码307 Temporary Redirect）授权并获取秘钥，然后重定向回原来的资源。在这种情况下，无需事先知道（即在某处硬编码）授权客户端的 URL 是什么，并且可以随时间调整此模式。
希望这将帮助您找到正确的解决方案！
TL;DR每个请求的登录不是实现 API 安全性的必需组件，身份验证是。
如果不谈论一般的安全性，很难回答您有关登录的问题。使用一些身份验证方案，没有传统的登录。
REST 没有规定任何安全规则，但实践中最常见的实现是具有 3 路身份验证的 OAuth（正如您在问题中提到的那样）。本身没有登录，至少每个 API 请求都没有。使用 3-way auth，您只需使用令牌。
该方案为用户提供了随时撤销访问权限的选项。我见过的几乎所有公开可用的 RESTful API 都使用 OAuth 来实现这一点。
我只是不认为您应该在登录方面提出您的问题（和问题），而应该考虑总体上保护 API。
有关一般 REST API 身份验证的更多信息，您可以查看以下资源：
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如果未提供，任何需要身份验证的请求都会返回。