为何部分服务器不支持HTTP DELETE请求携带Body参数？

1. HTTP规范的模糊性带来实现分歧 #

RFC7231第4.3.5节只明确DELETE请求的Payload无定义语义——既没禁止携带，也没规定统一的处理逻辑。这种模糊性让服务器库的实现者有了自主选择空间：为了避免跨系统兼容性问题（比如不同客户端、网关对DELETE Body的处理逻辑不一致），很多库干脆选择忽略或拒绝Body，以此维持行为的一致性。

2. 中间件与网关的默认过滤逻辑 #

很多Web服务器、反向代理（如Nginx、Apache）或框架底层的中间件，默认会过滤DELETE请求的Body。这是因为传统HTTP场景中，DELETE的目标完全由URL标识，不需要额外的Body参数。比如Next.js的路由处理依赖Node.js的http模块，该模块默认不会主动解析DELETE请求的Body；tsoa这类TypeScript API框架，也会继承这种默认行为，除非开发者手动配置开启。

3. RESTful实践的惯性影响 #

虽然REST不是HTTP强制标准，但它是当前API开发的主流范式，大部分库的设计都围绕RESTful场景优化。RESTful理念强调URL应唯一标识待操作资源，因此很多库默认假设DELETE只针对URL指向的单个/一组资源，不需要Body传递额外条件。对于你提到的/quotes?side=BUY这类批量删除场景，RESTful的常规做法可能是设计专门的资源路径（如/quotes/buy），但实际业务中确实存在需要用Body传递复杂删除条件的场景，只是这类场景不在库的默认覆盖范围内。

4. 规避语义混淆与潜在风险 #

允许DELETE携带Body可能带来语义模糊：到底是删除URL标识的资源，还是根据Body中的条件筛选删除？这种模糊性容易引发开发bug（比如误删非目标资源），部分库的开发者为了降低这种风险，直接禁止DELETE携带Body，强制开发者通过Query参数、路径参数或其他HTTP方法（如POST）实现批量删除逻辑。

补充：部分库可通过配置开启支持 #

需要注意的是，很多库并非完全不支持DELETE带Body，只是默认未开启。比如：

• Next.js可以在自定义API路由中，手动通过req.body获取DELETE请求的Body（需确保中间件没有过滤）；
• tsoa可以通过修改路由配置或自定义中间件，让框架解析DELETE请求的Body。

内容的提问来源于stack exchange，提问作者CHANist