Php RESTAPI设计：请求特定参数

我们有一个CORS REST API。它很干净。它起作用了。这几乎是完美的。但是

我正在尝试使用请求特定的参数实现端点。此端点应接受POST、PUT、LINK和DELETE请求。我不知道如何实现这些参数

例如： 用户希望删除模型。有两种情况：一种是模型被删除而没有其他任何事情发生，另一种是模型被删除+发送通知电子邮件

最初，我在一个名为“X-NOTIFY-OWNER”的头文件中实现了这个参数。这是有效的，因为它可以添加到4个动作中的任何一个。但是现在我们想去掉这个头，因为它太特定于这个单一端点了

什么是放置此参数的最佳位置？查询参数听起来最干净（因为DELETE和LINK技术上不需要主体），但查询参数应该用于过滤内容。请求主体中的参数也会起作用，并且似乎是首选的方法；但这意味着发送一个带有删除和链接操作的主体

---

对这种情况下的最佳实践有什么想法吗？

我会坚持使用查询字符串，DELETE应该忽略正文，只读取URL，这样在这里使用查询字符串才有意义。

我建议为最干净的解决方案设置一个新端点

example.com/endpoint

example.com/endpointAndNotify

你可以：

设置notify端点以扩展基本端点，然后将通知逻辑添加到notify操作

从两个操作中提取出共享逻辑，更新每个操作以扩展基类，然后将特定的通知逻辑添加到notify操作

---

这样，两个端点都保持干净简洁，如果为此端点定义了标准，则需要通知逻辑的任何其他端点都可以使用相同的标准。

您应该使用URL参数。正如您所说，它们应该用于过滤输出，并且可以将电子邮件视为输出。

X-NOTIFY-OWNER是请求或响应标题？它是请求标题老实说，我仍然最喜欢标题解决方案。该参数特定于请求。有人知道其他api做类似事情的例子吗？所以如果你仍然喜欢它，为什么要改变呢？您说过querystring参数用于内容过滤，所以请继续将其用于内容过滤。使用

X-

标题对我来说似乎既漂亮又干净，我怀疑你能得到比这更有意义或更简单的东西。在我看来，使用自定义头通知应用程序需要执行的额外任务是有意义的；这将变成：DELETE/meetings/{id}和DELETE/meetingsWithNotify/{id}。看起来不是一个干净的解决方案。