REST API登录模式
我创建了一个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临时重定向）以授权并获得密钥，然后重定向回原始资源。 在这种情况下，不需要事先知道（即，硬编码）什么URL来授权客户端，并且可以随时调整该架构。
希望这会帮助你找到适当的解决方案！
TL;每个请求的DR登录不是实现API安全所需的组件，身份验证是。
一般不谈论安全性就很难回答你关于登录的问题。 有了一些认证方案，就没有传统的登录方式。
REST并未规定任何安全规则，但实际中最常见的实现方式是具有3向身份验证的OAuth（如您在问题中所述）。 没有登录本身，至少没有每个API请求。 使用3向验证，您只需使用令牌。
该方案使用户可以随时撤销访问权限。 几乎所有公开的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识别/验证用户的具体方法。即使您没有通过公钥来识别用户，使用TLS / Diffie-Hellman来保护信道始终是一个好主意。）
例如：假设一个OAuth令牌是您的完整登录凭证。 一旦客户端拥有OAuth令牌，就可以通过标准HTTP身份验证中的每个请求将其作为用户ID提供。 服务器可以在第一次使用时验证令牌，并将支票的结果与生存时间一起缓存，每次请求都会更新。 如果没有提供任何要求认证的请求，则返回401