很奇怪的http删除rest操作-删除参数很多

分析团队制定了一些规范，这对我来说听起来有点奇怪。

我必须删除数据库表上的资源。我有 rekord 的 id 作为输入参数。

这是直接的 http 删除操作。

DELETE http://my-url/{id}

他们想添加一些其他值作为输入参数，出现在 rekord 中，因为，他们说“在这种情况下删除操作非常微妙，我们希望确保在前端排除错误，传递的 id 应该是是传递的 rekord 值的 id”。

有很多关于这个要求的内部讨论。菜肴在参与者之间飞来飞去。无论如何，我们必须满足它。

我知道这不是更多的 RESTful 操作。

我是这样修改的：

DELETE http://my-url/{id}
REQEUST BODY
{
    "myProperty1" = 123,"myProperty2" = "VALUE",...
}

Swagger 一代对带有 REQUEST BODY 的 DELETE 感到愤怒。

我必须切换到

开发团队喜欢尽可能长时间地呆在 RESTful 环境中。什么是最好不要走调？

我们认为不会受到赞赏的任何其他建议或解决方案。

Swagger 一代对带有 REQUEST BODY 的 DELETE 感到愤怒。

是的，没错。

DELETE 请求消息中的负载没有定义的语义 -- RFC 7231

DELETE 是将 URI 与其表示解耦。这有点类似于从地图/字典或文件系统中的符号链接中删除键。它告诉网络服务器停止提供特定的网页。

通常很容易找出 DELETE 请求的标识符；它将与您用来通过 GET 请求查找表示的标识符相同。

DELETE 是在 transfer of documents over a network 域中具有语义的操作。

注意标准中包含的这个观察：

允许使用 DELETE 方法的资源相对较少——它的主要用途是远程创作环境，用户对其效果有一定的指导。

如果您想要做的是将带有有效负载的消息传递到您的服务器，以便服务器可以做一些聪明的事情，您可能应该使用 POST，而不是 DELETE。

记住：it is okay to use POST。万维网使用 little more than GET and POST 取得了灾难性的成功。

这里所寻求的可能是 conditional 删除。我们有标准化的标头，validators 可以使用这些标头来确定 DELETE 请求和资源的当前状态是否“匹配”。