【问题标题】：How to design RESTful API without using verbs?如何在不使用动词的情况下设计 RESTful API？
【发布时间】：2020-02-09 09:57:48
【问题描述】：

编辑：

这个问题与“浏览器是否可以使用非 RESTful API”或“令牌授权标头”无关。这个问题与 API-Design（外观标签）、良好实践和 Authentication (/login) 相关，而不是 Authorization （令牌头）。

我知道如何制作 API，HTTP 协议如何工作，什么是 RPC，什么是 REST。如果您阅读我的问题，您可能会发现我理解这些原则。请仔细阅读我的问题。 不要只阅读标题本身并回答。您需要上下文才能回答。

我正在尝试设计一个不使用动词的 REST API。它变得越来越具有挑战性，因为我正在处理控制器等登录/身份验证之类的案例。

例如，我应该如何在 RESTful 服务中处理像 Authentication 这样的自然控制器？我可能在这里太迂腐了，如果我是请纠正我，但如果我的 API 包含类似的请求

GET /authenticate

那么根据定义，它不被认为是完全宁静的。正确的？我的意思是，这显然是一个动词。因此它是一个 RESTful+RPC API。

如果我违反了/authenticate 的 REST 原则，那么为什么我不应该在其他让我的生活更轻松的情况下违反我的 REST 原则呢？例如像其他一些业务控制器：

GET /users (noun) REST
POST /register (verb) RPC
GET /logout (verb) RPC

这似乎是一个非常语义化的问题，如果确实如此，我希望你告诉我，我可能以一种愚蠢的方式思考这个问题，所以我可以停止关心这个。但是，当 API RESTfull 中明显包含动词时，我觉得它真的很奇怪，所以这就是为什么我要征求你的意见。

否则，如果有更好的 RESTful 方式来执行身份验证，我会喜欢一些建议。由于在 Google 上很难找到有关该主题的答案，除了人们说“不要在 RESTful API 中使用动词”之外，在这种情况下会令人困惑。

免责声明：（针对不仔细的审稿人/读者）

这可能与您可能见过的其他一些问题不同，例如这个 How to create REST URLs without verbs?

我知道这个特定问题的正确解决方案是什么，因为 OP 提出的问题可以通过 REST 轻松完成。

我的问题更多的是语义，而不是关于如何执行基本 REST 操作（如更新用户字段）的问题。

我发现的这两个都不是重复的，但确实非常相似 REST API Login Pattern 用户问哪个是合适的 RESTful 设计，但他显然没有得到任何答案来回答我的问题。这是“如果您的 RESTful 设计中有 /login 路径，那么设计是否 RESTful”的语义（愚蠢与否）。 答案是关于授权，而不是身份验证。

我提出这个免责声明是因为我过去的一些问题被否决了，因为它们被认为是重复的，而实际上它们只是相似的，即使我没有得到答复，也从未删除过投反对票。 不过，如果您找到合适的副本，我将非常乐意接受。只是请不要粗鲁地重复，唯一的重复就是标题。

【问题讨论】：

你假设什么样的身份验证？换句话说，为什么你有一个/authenticate 端点？为什么不在每个资源上使用 Authorization 并在错误时返回 401？如果/authenticate URL（例如）要接收一个登录令牌以在以后的请求中使用，那么带有Authorization 标头的GET /loginToken 似乎适合“restful”命名。这也符合幂等思维。
（如果您认为Authorization 标头与授权有关，那是一种误解。Authorization 标头带有客户端的身份（身份验证））。我会等待回复，但这似乎是链接问题的语义重复。
用户是否必须首先登录才能获得Authorization 标头？这意味着，您实际上必须包含 /login 或 /authonticate 端点？
没有。除非你愿意。如果您的服务是通过 https 进行的，那么使用 HTTP Basic 是完全可以接受的。如果不是，那么这通常是由不同的（通常是预制的）服务负责发行代币的。资源端点只需验证Authorization（basic 或bearer）并在不满意时返回 401。 Redirects+Cookies 是可能的，但有点反模式，因为它假设一个交互式用户代理。
您可以根据需要使用令牌，但它们不是必需的。令牌 API 只是 GET /auth/token - 它仍然是面向资源的。令牌 API 只是将Authorization: basic（或其他一些身份验证机制）转换为Authorization: bearer 标头的工具——在架构上没有根本区别。（其他更改，是的。SSO、声明、双因素、MITM 缓解（如果正确完成，但通常不会更改 API）

标签： rest api-design

【解决方案1】：

具有本地登录的 REST 客户端和服务器示例如下：

服务器 API：

GET /users/currentUser
返回描述当前用户的 JSON 文档（显示名称、电子邮件地址、主题偏好、密码到期日期等...）
1. 验证Authorization: basic 标头中的用户名和密码，设置上下文。如果无效，则抛出 401
2. 检索用户信息，序列化，返回
GET /todos/
返回一个包含所有 TODO 项的 JSON 文档
1. 验证Authorization: basic 标头中的用户名和密码，设置上下文。如果无效，则抛出 401
2. 检索待办事项、序列化、返回

客户：

以“未验证”状态启动，显示登录 UI
单击登录按钮时，使用用户名和密码字段组成Authorization: basic 标头并将其添加到HTTP 客户端
使用标头对GET /users/currentUser 进行测试调用，以验证登录信息并检索用户信息。如果 401，登录失败 - 返回登录 UI。
保存 Authorization: basic 标头并转换到“已验证”状态，显示应用 UI
拨打GET /todos/，格式化并显示。如果发生 401，则转换到“未验证”状态（例如，其他客户端更改了密码）

【讨论】：