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


当前回答

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

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

也许下面的GitHUb url会帮助你,得到答案。 实际上,应用服务器,如Tomcat, Weblogic拒绝HTTP。带请求有效负载的DELETE调用。所以记住这些东西,我已经在github中添加了例子,请看看

https://github.com/ashish720/spring-examples

值得注意的是,OpenAPI 3.0版本的规范放弃了对带体的DELETE方法的支持:

请看这里和这里的参考资料

这可能会影响将来这些api的实现、文档或使用。

其他几个回答提到了RFC 7231,它有效地说了DELETE请求可以有一个主体,但不推荐。

在2022年,RFC 7231被RFC 9110: HTTP语义所取代,它现在说:

[...] content received in a DELETE request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection [...]. A client SHOULD NOT generate content in a DELETE request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.

这种语言在之前的语言基础上得到了加强,也就是说,即使它是允许的,在使用它时也需要非常小心,因为(例如)一些用户可能在代理的背后,为了打击“请求走私”而从请求中剥离主体。

有些版本的Tomcat和Jetty似乎会忽略存在的实体体。如果你想要收到它,那就麻烦了。