此问题与“浏览器将使用非静态API或Token授权标头使用”无关。此问题与 API设计（外观标记），良好做法和身份验证（/login）有关，而不与授权（令牌头）。
我知道如何制作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执行身份验证的方法，我希望提出一些建议。除了要说“ 不要在RESTful API中使用动词”之外，在Google上很难找到关于该主题的答案，这在这种情况下会令人困惑。
这可能不是您可能已经看到的其他一些问题的重复，例如这个 How to create REST URLs without verbs?
我知道这个特定问题的正确解决方案是什么，因为OP提出了REST可以轻松完成的事情。
我的问题更语义，而不是关于如何执行诸如更新用户字段之类的基本REST操作的问题。
我发现这都不是重复的，但确实非常相似 REST API Login Pattern 用户询问哪个是合适的RESTful设计，但他显然没有得到任何答案来回答我的要求。这是“如果您的RESTful设计中有/ login路径，设计就不再是RESTful”的语义（愚蠢的）。 答案是关于授权而不是认证。
之所以形成此免责声明，是因为我过去的一些问题已被否决，因为它们实际上是相似的，被认为是重复的，即使我从未得到答复，也从未删除过这些否决票。 尽管，如果您找到合适的副本，我将非常乐意接受。只是请不要粗鲁地抛出一个重复，唯一重复的是标题。
答案 0 :(得分：1)
具有本地登录名的示例REST客户端和服务器为：
服务器API：
GET /users/currentUser Authorization: basic标头中验证用户名和密码，设置上下文。如果无效，则抛出401 GET /todos/ Authorization: basic标头中验证用户名和密码，设置上下文。如果无效，则抛出401 客户：
Authorization: basic标头并将其添加到HTTP客户端GET /users/currentUser进行测试调用，以验证登录信息并检索用户信息。如果为401，则登录失败-返回登录界面。Authorization: basic标头并转换为“已认证”状态，显示应用程序用户界面GET /todos/，进行格式化和显示。如果出现401，请转换为“未经身份验证”状态（例如，其他客户端更改了密码）