在发出HTTP DELETE请求时,请求URI应该完全标识要删除的资源。但是,是否允许添加额外的元数据作为请求实体主体的一部分?


当前回答

我认为这个问题还没有一个好的答案,尽管已经有很多关于现有答案的很好的评论。我将把这些评论的要点升华为一个新的答案:

RFC7231中的这段话已经被引用了几次,这确实总结了它。

DELETE请求消息中的有效负载没有定义的语义; 在DELETE请求上发送有效负载主体可能会导致一些现有的问题 实现来拒绝请求。

我忽略了其他答案的含义。是的,允许在DELETE请求中包含一个主体,但这在语义上是没有意义的。这实际上意味着,发出带有请求体的DELETE请求在语义上等同于不包含请求体。

包含一个请求体不应该对请求有任何影响,所以包含它是没有意义的。

tl;dr:从技术上讲,一个带有请求体的DELETE请求是允许的,但是这样做是没有用的。

其他回答

2014年更新的HTTP 1.1规范(RFC 7231)明确地允许在DELETE请求中使用实体:

DELETE请求消息中的有效负载没有定义的语义;在DELETE请求上发送有效负载主体可能会导致某些现有实现拒绝该请求。

对Body使用DELETE是有风险的…比起REST,我更喜欢这种列表操作方法:

常规操作

GET /objects/获取所有对象

GET /object/ID获取指定ID的对象

POST /objects添加一个新对象

PUT /object/ID添加指定ID的对象,更新对象

DELETE /object/ID删除指定ID的对象

所有自定义操作都是POST

POST /objects/addList添加body中包含的对象列表或数组

POST /objects/deleteList删除包含在body中的对象列表

POST /objects/customQuery基于body中的自定义查询创建一个List

如果客户不支持您的扩展操作,他们可以以常规方式工作。

我认为这个问题还没有一个好的答案,尽管已经有很多关于现有答案的很好的评论。我将把这些评论的要点升华为一个新的答案:

RFC7231中的这段话已经被引用了几次,这确实总结了它。

DELETE请求消息中的有效负载没有定义的语义; 在DELETE请求上发送有效负载主体可能会导致一些现有的问题 实现来拒绝请求。

我忽略了其他答案的含义。是的,允许在DELETE请求中包含一个主体,但这在语义上是没有意义的。这实际上意味着,发出带有请求体的DELETE请求在语义上等同于不包含请求体。

包含一个请求体不应该对请求有任何影响,所以包含它是没有意义的。

tl;dr:从技术上讲,一个带有请求体的DELETE请求是允许的,但是这样做是没有用的。

实际答案:不

有些客户端和服务器会忽略甚至删除delete请求中的主体。在极少数情况下,它们会失败并返回错误。

只是一个提示,如果你在你的DELETE请求中提供了一个主体,并且使用了谷歌云HTTPS负载均衡器,它将拒绝你的请求,错误为400。我的头撞到墙上,然后发现谷歌,不管出于什么原因,认为一个带有主体的DELETE请求是一个畸形的请求。