为什么HTTP DELETE请求不推荐在响应中返回业务数据？

首先需要明确：REST规范的约定本质是对行业通用最佳实践的总结，要求DELETE返回空响应不是无意义的教条，背后有非常实际的工程价值考量：

• 接口职责解耦，降低维护成本
  DELETE接口的核心职责是处理指定资源的删除操作，若在其中耦合全量数据集的查询逻辑，相当于把删除、查询两个独立接口的能力绑定到了一起。后续如果列表查询逻辑发生调整（比如新增权限校验、字段过滤、聚合统计规则），需要同时修改DELETE和GET列表两个接口的实现，稍有不慎就会出现两个接口返回的数据集字段、规则不一致的问题，反而增加维护成本和线上故障风险。
• 兼容HTTP原生缓存机制，降低状态不一致概率
  HTTP缓存默认和请求方法、资源路径强绑定：DELETE请求执行成功后，浏览器/代理网关会自动失效该DELETE路径对应的资源缓存，而全量列表的缓存通常绑定到GET列表接口的路径上。如果DELETE返回全量数据集，你需要额外手动处理这部分返回数据的缓存更新逻辑，当有多个业务场景都用到该列表数据时，很容易出现不同场景拿到的列表数据不一致的问题。
• 适配多调用方场景，减少不必要的资源消耗
  同一个DELETE接口可能会被多个调用方使用，除了你当前的前端页面，还可能包括后台管理端、内部微服务、开放平台第三方开发者、定时任务脚本等。这些调用方大多不需要删除后的全量数据集，返回冗余数据会额外增加网络传输开销、序列化/反序列化的性能损耗，当数据集较大时，这种浪费会被进一步放大。
• 简化幂等性落地，避免调用方逻辑异常
  DELETE方法天然要求满足幂等性：同一个DELETE请求重复调用多次，对服务端状态的影响和调用一次完全一致。若DELETE返回动态的最新数据集，多次调用的返回内容可能会因为中间有其他新增/修改操作发生变化，虽然这并不违反幂等性的定义，但会导致很多依赖返回值做校验的调用方出现逻辑异常。返回空响应时，无论多少次调用返回内容都完全一致，不存在这类隐患。

当然上述都是通用场景的最佳实践，如果你能确认该DELETE接口只会服务于当前单一前端场景、没有其他调用方、返回的数据集体积很小，优先选择前端体验、省掉一次GET请求也是完全可行的，只是要提前评估好后续业务扩展的潜在成本。

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