Question

在定义REST API时，名词通常代表可以在其上应用HTTP动词的资源。

例如：GET /user/profile/{id}或POST /user/profile。

但并非所有功能都可以由典型资源表示。例如，需要验证注册密钥和机密的组合。如何在REST API中表示该方法？

Answer 1

您的问题的具体答案是：

POST to /RegistrationValidation
Request body:
{
    "key": "..."
    "secret": "..."
}

如果服务器接收到的数据有效，则响应为200 OK，否则为200。

这里的意思是：

您的API资源不应一对一映射到您的域模型。在设计API时，您不应该始终坚持CRUD风格。
您可以自由地选择细粒度，粗粒度样式的API，或者混合它们（如果最终适合的话）消费客户。任何动词都可以被“名词化”，并且您最终得到一个新的资源。您可以拥有一个正在修改多个基础域模型以解决特定业务需求的资源，这完全可以。但是，请与您的决定保持一致，不要忘记自由意味着责任。您拥有无限的URI空间，但请确保不要仅仅因为可以而获得大量资源。

当我写这个答案的时候，我想起了所有这些建议，我很高兴2014年的这篇文章还在继续，我真的很推荐： https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling

Answer 2

如何在REST API中表示实际上不是资源的函数？

您想问的几乎所有东西都是资源。来自Fielding's thesis：

REST中信息的关键抽象是一种资源。可以命名的任何信息都可以是资源：文档或图像，临时服务（例如“洛杉矶今天的天气”），其他资源的集合，非虚拟对象（例如人）等。换句话说，任何可能成为作者超文本引用目标的概念都必须符合资源的定义。资源是到一组实体的概念映射，而不是在任何特定时间点对应于该映射的实体。

target-uri只是一个标识符；它确实可以是您想要的任何东西。例如

/AAFE4035-C6E4-4897-B174-5FD0105DFF7A

是资源的完美标识符。

一种思考方式：资源标识符很像变量名。机器不在乎您使用什么拼写。拼写约定适用于人类。

有时，这种启发式方法会有所帮助：您将如何使用网站？用户将以一些加标签的URI开始，然后跟随链接并提交表单，直到完成工作为止。在这种情况下，您将使用什么标识符？