为什么有些服务器不接受HTTP DELETE中的body参数？

当我测试一个 API 时，我实际上遇到了这个问题，它不接受带有主体参数的 HTTP DELETE，但接受查询参数。这很好，但我不相信为什么不处理主体参数。

我实际上查看了 W3C 规范，它说了以下内容

DELETE 请求消息中的有效负载没有定义的语义； 在 DELETE 请求上发送有效负载正文可能会导致一些现有的拒绝请求的实现。

来源：https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.5

但是，它仍然没有解释为什么最初的设计是这样的。只是要求用户在 HTTP DELETE 中使用 body 参数时要小心。

我继续搜索，发现人们建议查询参数可以完全做同样的事情。为什么在 HTTP DELETE 请求中包含实体主体不是一个好习惯？

是的，我知道查询参数的工作原理。但为什么不支持身体参数呢？我还想到有人提到 RESTful，并认为 URL 应该已经标识要删除的资源。

但是，我在网上找到了一些API，例如根据我的理解，下面的似乎无法识别要删除的资源。例如/quotes?side=BUY，删除所有买入报价，但您不知道要取消哪个报价。

当然，RESTful只是一个概念，并不是HTTP规范中每个人都需要遵守的规则。这样服务器就可以正常回复了。

那么回到问题，为什么某些服务器库/标准不接受 HTTP DELETE 中的主体参数？

例如服务器端不支持HTTP DELETE body参数https://github.com/lukeautry/tsoa/issues/362

例如前端库不支持 HTTP DELETE body 参数 https://github.com/vercel/next.js/issues/49353

0
投票

那么回到问题，为什么某些服务器库/标准不接受 HTTP DELETE 中的主体参数？

可能的答案：因为接受身体参数充其量不会做任何有用的事情，更糟糕的是会造成混乱。

从结构上讲，DELETE 很像 HEAD - 您需要了解请求意图的所有信息都在那里：“请删除请求行中标识的资源”。

具有这些语义的消息没有理由需要实体，因此当 RFC 2068 指定“只有当请求方法（第 5.1.1 节）允许实体时，[a] 消息正文才可以包含在请求中-body”，只有 PUT 和 POST 的描述才允许请求实体。

所使用的语言并非完全没有问题，特别是它混淆了消息结构的约束和语义的约束 - 现代拼写是：

虽然请求消息帧独立于所使用的方法，但 DELETE 请求中接收的内容没有一般定义的语义，不能改变请求的含义或目标，并且可能导致某些实现拒绝请求并关闭连接，因为它的潜在的请求走私攻击 -- RFC 9110

但是，我在网上找到的一些API...

是的。我会这样总结您的发现：网络上的一些 API 是由对 HTTP 和/或 REST 统一接口约束理解存在差距的人设计的。

在现实中，如果存在不符合 HTTP 统一接口的 API（甚至可能是有用的 API），库维护者和标准作者需要选择是否支持与不符合要求的 API 集成。问题是，这不是你通过抛硬币做出的决定，而是需要评估许多不同的权衡。

（这本身就是一个广泛的主题；阅读波斯特尔定律/稳健性原则，然后阅读尝试遵循该原则所产生的问题数量。）