我有一个关于REST的API设计的问题。 继REST的指导方针，所有的终端应该是名词，复数，而且永远不应该动词。 然而，习惯上有认证的路线是：
/login
/logout
这两者都是动词。 如果您应该是真实的准则，这些路线应该看起来更像这个：
/users?action=login
/users?action=logout
但我从来没有使用具有这种特殊的身份认证实施方案的任何API，每个人都使用第一个，包括我在内。 但我不知道这是因为很多人不遵守的准则完全，它刚刚成为一种习惯或者是有其他的原因？
如果你想成为符合剩下的准则，例如如下的API应该暴露的安全令牌资源：
/security/token
就是这样......那么你可以得到安全令牌（登录），使用它们，然后将其删除（注销）
按照REST的无状态约束维持在服务器端客户端会话是不允许的。 所以你的问题没有任何意义。 这些是REST最简单的解决方案，权威性：
由受信任的客户，你必须有一个HTTP（基本）身份验证头例如每个请求发送用户名和密码。 你必须使用加密连接。
由第三方（非信任）客户端，你必须注册一个独特的API密钥添加到客户端。 此后，当用户第一次尝试使用客户端告诉你她在那里她可以注册为客户端的唯一访问令牌的对话框。 于是就这样，她可以访问她的账户。 在此之后，第三方客户端发送与每一个相关的客户账户请求的API密钥和访问令牌。
为您解答相关的URI的问题。 根据统一接口约束 ：
你映射的URI资源，而不是操作。 这就是为什么他们不应该包含动词。 您可以使用动词来选择适当的HTTP方法。 你可以几乎所有的操作名减少到几个HTTP方法和漂亮的URI。
的URI不具有意义的客户，因为客户端遵循语义（如注释超链接的链接关系 ，或从一个RDF词汇术语 ）。
尼斯URI是很好的检查，如果你真的它们映射到的资源（如果没有，那么它们所包含的动词）。
当你手动编写服务器端的路由逻辑，或当你调试请求的URI尼斯是好的。
使用JWT（JSON网络令牌）。 这是非常轻便。
