如何在不使用动词的情况下设计RESTful API？

Question

我正在尝试不使用动词来设计REST API。随着我遇到诸如Login / Authentication之类的控制器之类的问题，这变得越来越具有挑战性。

[例如，我应该如何在RESTful服务中将自然控制器像Authentication那样对待？如果可能，请纠正我，但如果我的API包含类似[]的请求，我可能在这里太学究了

GET /authenticate
然后，根据定义，它并不完全宁静。对？我的意思是，这显然是一个verb
。因此，这是一个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”的语义（愚蠢的）。

答案是关于授权而不是认证。

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

我正在尝试不使用动词来设计REST API。随着我遇到诸如控制器之类的“登录/身份验证”之类的问题，这变得越来越具有挑战性。就像，我应该如何对待自然...

Answer 1

如何不使用动词来设计RESTful API？