REST中使用GET方法执行删除操作存在哪些技术弊端及潜在问题？

作为常年跟REST架构打交道的开发者，我得说这种做法确实踩了不少规范和实践上的坑，下面给你拆解具体的问题：

1. 违反HTTP语义规范，破坏REST设计原则 #

HTTP方法本身有明确的语义：GET的定义是安全且幂等的"获取资源"操作，不应该对服务器状态产生任何修改（也就是所谓的"副作用"）。而删除操作属于修改服务器状态的写操作，按照规范应该用DELETE方法。

这种语义混淆会让其他开发者、API工具（比如Postman、Swagger）甚至服务器中间件误解你的接口行为，大幅增加维护成本——比如新人接手时看到GET /users/123第一反应是获取用户信息，结果实际是删除用户，完全反直觉。

2. 缓存与预加载引发的意外删除 #

浏览器、CDN、代理服务器都会对GET请求做自动缓存，甚至有些浏览器会预加载它认为可能用到的GET链接（比如鼠标悬停在链接上时）。想象一下：

• 用户刚打开页面，浏览器预加载了GET /delete/article/456，结果文章直接被删了，用户根本没主动触发删除操作；
• CDN缓存了这个删除请求的响应，后续其他用户访问同样的GET链接时，CDN直接返回缓存的"删除成功"响应，但实际服务器上的资源可能还在，或者重复执行删除导致逻辑错误。

3. 敏感数据泄露与权限风险 #

GET请求的参数和资源路径会直接暴露在URL里，删除操作的目标资源ID（比如/delete/user/789）会被记录在服务器日志、浏览器历史、代理日志里，敏感数据泄露的风险更高。

另外，很多安全策略会默认认为GET是"安全操作"，可能跳过部分权限校验；反过来，WAF（Web应用防火墙）可能会把带有删除语义的GET请求标记为异常流量，直接拦截，导致接口不可用。

4. 工具链与兼容性问题 #

很多API客户端、测试工具、后端框架会对GET请求做特殊处理：比如不允许在GET请求里带请求体（虽然HTTP规范没禁止，但绝大多数工具不支持），如果你的删除操作需要额外参数（比如删除原因、批量删除ID列表），用GET就会非常麻烦。

而且RESTful框架（比如Spring Boot、Express）的路由机制通常会把GET和DELETE分开处理，强行用GET做删除会增加不必要的配置，还容易和正常的查询接口冲突。

5. 幂等性失控 #

虽然DELETE也是幂等的（多次调用同一个删除接口，结果应该和一次调用一致），但GET的缓存和预加载会让幂等性变成噩梦——你根本控制不了请求会被触发多少次。比如用户不小心刷新页面，可能会重复触发删除，导致后续的业务逻辑出现异常（比如统计数据错乱）。

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