我正在创建一款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风格的方式登录用户？
现代Web架构的原则设计，作者为Roy T. Fielding和Richard N. Taylor, 即所有REST术语序列来源于该文，其中包含客户端-服务器交互的定义:
所有REST交互都是无状态的。也就是说，每个请求都包含了所有必要的信息，使连接器能够理解该请求，独立于之前可能存在的任何请求。
这种限制实现了四个功能，其中第1个和第3个在这种情况下非常重要：
现在让我们回到您的安全案例。每个请求都应包含所有必需的信息，授权/认证也不例外。如何做到这一点？字面意义上发送每个请求中所需的所有信息。
其中一个实现方法是基于哈希的消息认证码或HMAC。实际上，这意味着将当前消息的哈希代码添加到每个请求中。哈希代码是通过密码散列函数与秘密密码密钥相结合计算得出的。 密码散列函数可以是预定义的，也可以是按需编码REST概念的一部分（例如JavaScript）。秘密密码密钥应由服务器提供给客户端作为资源，并且客户端使用它来为每个请求计算哈希代码。
有很多HMAC实现的示例，但我想让您注意以下三个：
如果客户端知道秘密密钥，则可以操作资源。否则，它将被临时重定向（状态码307临时重定向）以进行授权并获取秘密密钥，然后重定向回原始资源。在这种情况下，无需预先知道（即在某处硬编码）用于授权客户端的URL，并且可以随时间调整此模式。
希望这可以帮助您找到合适的解决方案！
简而言之，每个请求的登录并非实现API安全性所必需，身份验证才是。
谈到登录时很难不谈及安全性问题。在某些身份验证方案中，没有传统的登录。
REST没有规定任何安全规则，但在实践中最常见的实现方式是OAuth 3向身份验证（正如您在问题中提到的）。至少不是每个API请求都需要登录。使用三向身份认证，您只需使用令牌。
此方案使用户可以随时撤销访问权限。我看到的几乎所有公开可用的RESTful API都使用OAuth来实现此操作。
我认为您不应该将自己的问题（和问题）框定在登录方面，而应该考虑整体保护API的安全性。
有关一般情况下对REST API进行身份验证的更多信息，您可以查看以下资源：
REST哲学的一个重要部分是在设计API时尽可能利用HTTP协议的标准特性。 在身份验证方面应用这一哲学，客户端和服务器将在API中使用标准的HTTP身份验证功能。
登录界面非常适用于人类用户情况：访问登录界面，提供用户名/密码，设置cookie，客户端在所有未来请求中提供该cookie。不能期望使用Web浏览器的人每个HTTP请求都提供一个用户名和密码。
但对于REST API而言，登录界面和会话cookie并不是必需的，因为每个请求都可以包含凭据，而不影响人类用户；如果客户端任何时候不合作，则可以给出“未经授权”的401响应。 RFC 2617描述了HTTP中的身份验证支持。
TLS（HTTPS）也是一种选择，并且可以通过验证另一方的公钥来在每个请求中对客户端和服务器进行身份验证。此外，这还可为我们提供了安全通道的额外保障。当然，需要在通信之前进行密钥交换才能实现这一点。（请注意，这与使用TLS / Diffie-Hellman保护通道无关的用户识别/身份验证。即使您不使用公钥标识用户，使用TLS / Diffie-Hellman保护通道也总是一个好主意。）
举个例子：假设OAuth令牌是您的完整登录凭据。一旦客户端拥有OAuth令牌，则可以在每个请求中将其作为标准HTTP身份验证的用户ID提供。服务器可以在首次使用时验证令牌并缓存检查结果，并与每个请求一起更新具有生存时间的TTL。任何需要身份验证的请求如果没有提供则返回401。