我有使用此资源构建的其余API
POST /backend/entities/Donut
根据给定的JSON有效负载创建一个新实体。
我的后端具有一个实体链接机制，因此我打算创建此资源作为创建一个新实体的简写，并且还创建另一个链接到它的实体，如下所示：
POST /backend/entities/Donut?entityType=Box&linkName=donut
这是创建一个Donut实体（给定JSON有效负载，此处未显示），然后创建另一个名为Box的实体，然后将Donut链接到链接名称为donut的新Box，对我来说，这是一种操作，以同样的方式，对我来说，HTTP查询参数仅用于查询（或查询过滤器）而不用于操作。
此方法的动机是使用相同的Entity字段保持JSON有效负载不变，而不会添加其他令人困惑的Entity-inside-Entity JSON。另一个原因是在一个HTTP请求中只有一个请求“创建一个新实体然后创建一个链接到它的新实体”。
这种方法是否仍然RESTful？还是添加这样的查询参数只会使其看起来像查询过滤器？
答案 0 :(得分：1)
REST中没有任何规则限制您在标识符中使用查询参数的方式。
/a/b/c
/a/b?c
这两个拼写都很好。
RFC 3986指定了URI结构，但是它对URI语义非常宽容
路径组件包含通常以分层形式组织的数据，以及非分层查询组件中的数据...
查询组件包含非分层数据，以及路径组件中的数据...
从客户端的角度来看，服务器是否将信息编码为路径，查询或两者都无关紧要。整个过程是一个不透明的参数。
（二十年前，这还不那么正确-有许多实现尝试将查询部分用作缓存提示，因此您可能选择的拼写将继续适用于残破的客户端。相信这是2019年的问题。）
机器不在乎；但是人类可能会。具有一致的编码信息位置的API将更容易理解，就像具有一致的变量命名约定使代码更易于理解一样。但是在API中使用哪种约定并不是特别重要。