No, you cannot use the OpenAPI 3.0 Specification and Swagger tools to implement DELETE requests with a request body. As you correctly pointed out, the HTTP RFC says the DELETE request body has no defined semantics (and thus should be avoided), and OpenAPI 3.0 specifically disallows bodies in HTTP methods where the body does not have defined semantics. See this discussion for some context.
Consider changing your API design, for example, replace the DELETE body with path, query string or header parameters. Check out RESTful Alternatives to DELETE Request Body for some ideas.
No, you cannot use the OpenAPI 3.0 Specification and Swagger tools to
implement DELETE requests with a request body. As you correctly pointed out, the HTTP RFC says the DELETE request body has no defined semantics (and
thus should be avoided), and OpenAPI 3.0 specifically disallows bodies in
HTTP methods where the body does not have defined semantics. See this
discussion for some context.
Consider changing your API design, for example, replace the DELETE body with path, query string or header parameters. Check out RESTful Alternatives to DELETE Request Body for some ideas.
大家怎么看？我折腾了一下，好像req.params, req.body都可以有了
简单说个人结论：http协议里没说有，也没强制没有，大多数实现不对request body根据http method做限制，具体需要查看文档和代码确认。
Delete 还不是很典型，GET的request body才让人纠结。rest principle 里建议使用
GET获取数据，不能使用body，假设你有个非常复杂的查询，用json表达很简单，但通
过query param 就比较痛苦。记得以前elasticsearch专门讨论过在GET里使用body传递search query。一般的http服务实现都
另外通讯链路上所有的http处理都有一个buffer size限制，一路从过去4k升到8k、16k，甚至32k，依然不像body那样可以几个M。 如果使用大的buffer size，单个节点的处理能力和性能就会受影响，用小的，无法传输大量数据来构建复杂查询。这个buffer不光给query用，包括所有的http header数据。
"rest principle 里建议使用GET获取数据，不能使用body"
这样的建议是BS。
【 在 sanwadie (三娃爹) 的大作中提到: 】
: 简单说个人结论：http协议里没说有，也没强制没有，大多数实现不对request body根
: 据http method做限制，具体需要查看文档和代码确认。
: Delete 还不是很典型，GET的request body才让人纠结。rest principle 里建议使用
: GET获取数据，不能使用body，假设你有个非常复杂的查询，用json表达很简单，但通
: 过query param 就比较痛苦。记得以前elasticsearch专门讨论过在GET里使用body传递
: search query。一般的http服务实现都
: 另外通讯链路上所有的http处理都有一个buffer size限制，一路从过去4k升到8k、
16k
: ，甚至32k，依然不像body那样可以几个M。 如果使用大的buffer size，单个节点的处
: 理能力和性能就会受影响，用小的，无法传输大量数据来构建复杂查询。这个buffer不
: 光给query用，包括所有的http header数据。
2年多前有过讨论。你查查旧贴看还在不。三娃爹比较熟悉这些。
我觉得yahoo finance YQL设计的很好。有参考价值。
【 在 somehow(愿我的生命璀璨) 的大作中提到: 】
: "rest principle 里建议使用GET获取数据，不能使用body"
: 这样的建议是BS。
: 16k
我司所有request都是post，body里边有个field，比如method: "get"
我这不就是想避免全用post 吗？
我就觉得那个不能有body的rule真他妈的sb
【 在 fantasist (一) 的大作中提到: 】
: 我司所有request都是post，body里边有个field，比如method: "get"
用post吧，url好像只能放2000个字符，还有可能被cache。我最近也有同样需求，最后用post送body了事
[在 somehow (愿我的生命璀璨) 的大作中提到：]
:我这不就是想避免全用post 吗？
:我就觉得那个不能有body的rule真他妈的sb
這服務器是你寫得嗎？否則why do you care? 愛怎麼解析協議怎麼解析。
如果不是，那你沒啥好說的，老老實實按服務器規範寫。
【 在 somehow (愿我的生命璀璨) 的大作中提到: 】
: 我这不就是想避免全用post 吗？
: 我就觉得那个不能有body的rule真他妈的sb
哈哈。這是個核心問題。server文檔規範往往有好多細節。有時候很難follow，client很多
怨气。
我解決的办法是server要写一些quick start的简单python例子。
这样大家轻松些。
【 在 netghost(Up to Isomorphism) 的大作中提到: 】
: 這服務器是你寫得嗎？否則why do you care? 愛怎麼解析協議怎麼解析。
: 如果不是，那你沒啥好說的，老老實實按服務器規範寫。
整个http header 受服务器buffer size 限制，包括http header 里的东西和 url，现在一般的默认值是8k，可以通过配置调整
【 在 pda (天与地) 的大作中提到: 】
: 用post吧，url好像只能放2000个字符，还有可能被cache。我最近也有同样需求，最后
: 用post送body了事
: [在 somehow (愿我的生命璀璨) 的大作中提到：]
: :我这不就是想避免全用post 吗？
: :我就觉得那个不能有body的rule真他妈的sb
我自己的一些教训：
复杂数据传递，用get最终碰到两个问题：
1、处理代码复杂，调试不方便
2、碰到尺寸限制，如果架构复杂，中间有多个网关，受最小那个限制，虽然可以修改
配置，但非常麻烦
我们最终还是使用post。使用get + request body虽然没遇到问题，但毕竟不符合规范，怕代码移植到不同的云平台会受影响
【 在 somehow (愿我的生命璀璨) 的大作中提到: 】
: 我这不就是想避免全用post 吗？
: 我就觉得那个不能有body的rule真他妈的sb
如果有代码洁癖，一定要get，且尺寸允许，我以前的做法是：
转换成json，然后压缩再base64，通过一个query param 传递，在服务器端转换回来。如果用spring，通过custom data binder，代码还是很干净的
【 在 sanwadie (三娃爹) 的大作中提到: 】
: 我自己的一些教训：
: 复杂数据传递，用get最终碰到两个问题：
: 1、处理代码复杂，调试不方便
: 2、碰到尺寸限制，如果架构复杂，中间有多个网关，受最小那个限制，虽然可以修改
: 配置，但非常麻烦
: 我们最终还是使用post。使用get + request body虽然没遇到问题，但毕竟不符合规范
: ，怕代码移植到不同的云平台会受影响
非常感谢！以后接着请教！
【 在 sanwadie (三娃爹) 的大作中提到: 】
: 我自己的一些教训：
: 复杂数据传递，用get最终碰到两个问题：
: 1、处理代码复杂，调试不方便
: 2、碰到尺寸限制，如果架构复杂，中间有多个网关，受最小那个限制，虽然可以修改
: 配置，但非常麻烦
: 我们最终还是使用post。使用get + request body虽然没遇到问题，但毕竟不符合规范
: ，怕代码移植到不同的云平台会受影响