Web服务器拦截DELETE请求时删除接口应选POST还是PUT实现

直接用POST，别选PUT。

• 别搞反HTTP方法的语义逻辑
  PUT的核心定义是：你携带目标资源的完整表述，用这个内容全量替换URI指向的资源状态。幂等是这个操作自带的属性，不是说“只要我接口做的幂等，就可以随便用PUT”。
  你设计的路径是/{entity}/{code}/delete，这本质是个触发删除动作的操作端点，不是一个需要被全量替换的独立资源。要是硬用PUT，别的开发看到请求第一反应会是“哦，这是要修改这个资源下delete子资源的内容”——比如是不是要更新删除标记、改删除策略？平白增加语义歧义。
  而POST的语义本来就包含“请求服务器执行指定的处理逻辑”，用来触发删除动作完全符合HTTP规范，没有任何问题。
• 幂等性和POST不冲突
  很多人对POST有刻板印象，觉得POST就必须是非幂等的，实际上HTTP规范从来没做过这个限制——规范只是说POST不强制要求实现幂等，你完全可以把POST接口做成幂等的，一点都不违规。
  你下游调用的DELETE本身就是幂等的，你只需要在自己的API层做个简单兼容：第一次请求转发下游删除成功后，后续重复收到相同的删除请求，要么直接返回成功，要么返回资源不存在的常规错误，别抛系统级异常，就能保证整个接口幂等，这和你选不选POST没关系。
• 这是业内通用的兼容方案
  不管是WAF、反向代理还是内部网关拦截DELETE、PUT这类非GET/POST方法的情况都非常常见，用POST /{资源路径}/delete代理删除请求是已经跑了很多年的成熟方案，没有设计硬伤。

补充个可选方案：如果不想新增路径，也可以在POST请求里加X-HTTP-Method-Override: DELETE的自定义头，告诉后端这实际是个删除请求，但前提是你们的网关不会拦截这个自定义头。相比之下你现在选的加/delete后缀的方案更直白，后续排查问题的时候一眼就能看明白请求用途，优先级更高。

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