用动作设计restapi

我有一个RESTAPI，我正在用这个资源构建它

POST /backend/entities/Donut

在给定JSON负载的情况下创建新实体

我的后端具有实体链接机制，因此我计划创建此资源作为创建新实体的速记，并创建另一个链接到它的实体，如下所示：

POST /backend/entities/Donut?entityType=Box&linkName=donut

这样做是为了创建一个给定JSON负载的甜甜圈实体，这里没有显示，然后创建另一个名为Box的实体，然后用链接名Donut将甜甜圈链接到新的Box，对我来说这是一种操作，HTTP查询参数对我来说，以同样的方式，只是用于查询或查询过滤器，而不是用于操作

这种方法的动机是使用相同的实体字段来保持JSON有效负载，而不在实体JSON中添加额外的实体，这会让人感到困惑。另一个原因是有一个将创建一个新实体的请求，然后在一个HTTP请求中创建一个链接到它的新实体

---

这种方法仍然是RESTful的吗？或者添加这样的查询参数只是让它看起来像一个查询过滤器

REST中没有限制如何在标识符中使用查询参数的规则

/a/b/c
/a/b?c

这两种拼写都很好

指定URI结构，但它非常宽容URI语义

路径组件包含数据，通常以分层形式组织，与非分层查询组件中的数据一起

查询组件包含非分层数据，这些数据与路径组件中的数据一起

从客户机的角度来看，服务器是否将信息编码到路径、查询或两者都编码并不重要。整个过程是一个不透明的参数

二十年前，这一点就不那么正确了——有许多实现试图使用查询部分作为缓存提示，因此您可能会选择拼写，以继续处理损坏的客户端。我不认为2019年会出现这样的问题

机器不在乎；但人类可能会。拥有一个关于编码信息的位置保持一致的API将更容易理解，就像拥有一致的变量命名约定使代码更容易理解一样。但在API中使用哪种约定并不特别重要