RESTful API 不用动词怎么设计？
How to design RESTful API without using verbs?
编辑：
此问题与"will the browser work with a non-restful API"或"Token authorization headers"无关。这个问题与API-Design（查看标签）、良好做法和身份验证有关(/login)，不是授权（令牌header）。
我知道如何制作 API、HTTP 协议的工作原理、什么是 RPC 以及什么是 REST。如果您阅读我的问题，您可能会发现我理解这些原则。请仔细阅读我的问题。 不要只看标题本身就回答。您需要上下文才能回答。
我正在尝试 设计 REST API 而不使用动词。它变得越来越具有挑战性，因为我正在面对 Login/Authentication 这样的案例，比如控制器。
比如，在 RESTful 服务中，我应该如何对待像 Authentication 这样的自然控制者？我可能在这里太迂腐了，如果我是请纠正我，但如果我的 API 包含像
这样的请求
GET /authenticate
那么根据定义，它不被认为是完全 restful。正确的？我的意思是，这显然是一个 动词 。因此它是一个 RESTful+RPC API.
如果我为了 /authenticate 违反了我的 REST 原则，那么为什么我不应该为了让我的生活更轻松的其他情况而违反我的 REST 原则？例如像其他一些业务控制器：
GET /users (noun) REST
POST /register (verb) RPC
GET /logout (verb) RPC
这似乎是一个非常语义化的问题，如果确实如此，我希望你告诉我我可能以一种愚蠢的方式思考这个问题，所以我可以不再关心这个了。但是当 API RESTfull 中明显包含动词时，我真的觉得很奇怪，所以这就是为什么我要征求你的意见。
否则，如果有更好的RESTful方式来执行身份验证，我会喜欢一些建议。因为很难找到关于 Google 主题的答案，除了人们说“不要在 RESTful API 中使用动词”，这令人困惑在这种情况下。
免责声明：（不小心reviewers/readers）
这可能不是您可能已经看到的其他一些问题的重复，例如这个问题
How to create REST URLs without verbs?
我知道这个特定问题的正确解决方案是什么，因为 OP 要求的东西可以通过 REST 轻松完成。
我的问题更多是语义，而不是关于如何执行基本 REST 操作（如更新用户字段）的问题。
我发现的这两个都不是重复的，但确实非常相似
REST API Login Pattern
用户询问哪个是合适的 RESTful 设计，但他显然没有得到任何答案来回答我的问题。这是 "Is the design RESTful anymore if you have a /login path in your RESTful design" 的语义（愚蠢与否）。 答案是关于授权，而不是身份验证。
我形成这个免责声明是因为我过去的一些问题被否决了，因为它们被认为是重复的，而实际上它们只是相似的，而且即使我没有得到回复，否决票也从未被删除.
不过，如果您找到合适的副本，我会非常乐意接受。请不要粗鲁地抛出一个重复的东西，唯一重复的东西就是标题。
具有本地登录的 REST 客户端和服务器示例为：
服务器 API 的：
GET /users/currentUser
Returns 描述当前用户的 JSON 文档（显示名称、电子邮件地址、主题偏好、密码到期日期等... )
- 验证
Authorization: basic header 中的用户名和密码，设置上下文。如果无效，则抛出 401
- 获取用户信息，序列化，return
GET /todos/
Returns 包含所有 TODO 项的 JSON 文档
- 验证
Authorization: basic header 中的用户名和密码，设置上下文。如果无效，则抛出 401
- 检索 To-Do 项，序列化，return
客户：
- 以"Unauthenticated"状态启动，显示登录UI
- 点击登录按钮后，使用用户名和密码字段组成一个
Authorization: basicheader并添加到HTTP客户端
- 使用 header 对
GET /users/currentUser 进行测试调用以验证登录信息并检索用户信息。如果 401，登录失败 - return 登录 UI.
- 保存
Authorization: basicheader并过渡到"Authenticated"状态，显示appUI
- 调用
GET /todos/，格式化并显示。如果发生 401，转换到 "Unauthenticated" 状态（例如密码被其他客户端更改）
编辑：
此问题与"will the browser work with a non-restful API"或"Token authorization headers"无关。这个问题与API-Design（查看标签）、良好做法和身份验证有关(/login)，不是授权（令牌header）。
我知道如何制作 API、HTTP 协议的工作原理、什么是 RPC 以及什么是 REST。如果您阅读我的问题，您可能会发现我理解这些原则。请仔细阅读我的问题。 不要只看标题本身就回答。您需要上下文才能回答。
我正在尝试 设计 REST API 而不使用动词。它变得越来越具有挑战性，因为我正在面对 Login/Authentication 这样的案例，比如控制器。
比如，在 RESTful 服务中，我应该如何对待像 Authentication 这样的自然控制者？我可能在这里太迂腐了，如果我是请纠正我，但如果我的 API 包含像
GET /authenticate
那么根据定义，它不被认为是完全 restful。正确的？我的意思是，这显然是一个 动词 。因此它是一个 RESTful+RPC API.
如果我为了 /authenticate 违反了我的 REST 原则，那么为什么我不应该为了让我的生活更轻松的其他情况而违反我的 REST 原则？例如像其他一些业务控制器：
GET /users (noun) REST
POST /register (verb) RPC
GET /logout (verb) RPC
这似乎是一个非常语义化的问题，如果确实如此，我希望你告诉我我可能以一种愚蠢的方式思考这个问题，所以我可以不再关心这个了。但是当 API RESTfull 中明显包含动词时，我真的觉得很奇怪，所以这就是为什么我要征求你的意见。
否则，如果有更好的RESTful方式来执行身份验证，我会喜欢一些建议。因为很难找到关于 Google 主题的答案，除了人们说“不要在 RESTful API 中使用动词”，这令人困惑在这种情况下。
免责声明：（不小心reviewers/readers）
这可能不是您可能已经看到的其他一些问题的重复，例如这个问题 How to create REST URLs without verbs?
我知道这个特定问题的正确解决方案是什么，因为 OP 要求的东西可以通过 REST 轻松完成。
我的问题更多是语义，而不是关于如何执行基本 REST 操作（如更新用户字段）的问题。
我发现的这两个都不是重复的，但确实非常相似 REST API Login Pattern 用户询问哪个是合适的 RESTful 设计，但他显然没有得到任何答案来回答我的问题。这是 "Is the design RESTful anymore if you have a /login path in your RESTful design" 的语义（愚蠢与否）。 答案是关于授权，而不是身份验证。
我形成这个免责声明是因为我过去的一些问题被否决了，因为它们被认为是重复的，而实际上它们只是相似的，而且即使我没有得到回复，否决票也从未被删除. 不过，如果您找到合适的副本，我会非常乐意接受。请不要粗鲁地抛出一个重复的东西，唯一重复的东西就是标题。
具有本地登录的 REST 客户端和服务器示例为：
服务器 API 的：
GET /users/currentUser
Returns 描述当前用户的 JSON 文档（显示名称、电子邮件地址、主题偏好、密码到期日期等... )- 验证
Authorization: basicheader 中的用户名和密码，设置上下文。如果无效，则抛出 401 - 获取用户信息，序列化，return
- 验证
GET /todos/
Returns 包含所有 TODO 项的 JSON 文档- 验证
Authorization: basicheader 中的用户名和密码，设置上下文。如果无效，则抛出 401 - 检索 To-Do 项，序列化，return
- 验证
客户：
- 以"Unauthenticated"状态启动，显示登录UI
- 点击登录按钮后，使用用户名和密码字段组成一个
Authorization: basicheader并添加到HTTP客户端 - 使用 header 对
GET /users/currentUser进行测试调用以验证登录信息并检索用户信息。如果 401，登录失败 - return 登录 UI. - 保存
Authorization: basicheader并过渡到"Authenticated"状态，显示appUI - 调用
GET /todos/，格式化并显示。如果发生 401，转换到 "Unauthenticated" 状态（例如密码被其他客户端更改）