为什么很多大厂 API 不再使用 PUT 和 DELETE？

沉默是金，总会发光

大家好，我是沉默

在大多数 RESTful API 教程中，我们都会看到一套经典映射关系：

方法	含义
GET	获取资源
POST	创建资源
PUT	更新资源
DELETE	删除资源

这种设计看起来 清晰、优雅、符合规范。

但如果你观察很多 大型互联网公司的 API 设计，会发现一个有意思的现象：

很多核心接口 很少直接使用 PUT 和 DELETE ，反而更常使用 POST 或 PATCH 来完成更新、删除等操作。

这就让人产生疑问：

既然 RESTful 推荐使用 PUT 和 DELETE，为什么在真实的大型系统中却越来越少见？

实际上，当系统进入 高并发、分布式、复杂业务场景 时，API 设计往往需要在 规范、灵活性、安全性和工程实践之间做权衡。

接下来，我们就一起看看：
PUT 和 DELETE 在工程实践中为什么逐渐被"弱化"，以及大厂通常是如何设计 API 的。

**-**01-

PUT 与 DELETE 的设计初衷

HTTP 在设计之初，其实非常优雅。

RESTful 架构把 HTTP 方法和资源操作做了严格映射：

方法	含义
GET	获取资源
POST	创建资源
PUT	完整更新资源
PATCH	部分更新资源
DELETE	删除资源

例如：

更新用户信息

bash 复制代码

PUT /users/12345

perl 复制代码

{
"name": "Alice",
"email": "alice@example.com",
"age": 30
}

PUT 的语义非常明确：

用新的资源完全替换旧资源

如果缺字段，就会被删除。

删除资源

bash 复制代码

DELETE /users/12345

服务器返回

css 复制代码

204 No Content

表示资源已经被删除。

在纯 REST 理念下：

PUT 更新资源
DELETE 删除资源

非常干净。

但是，

真实世界的系统，很少这么简单。

- 02-

为什么现实系统很少使用 PUT 和 DELETE

很多开发者会发现：

在公司系统里常见的是：

sql 复制代码

POST /order/cancel
POST /user/update
POST /order/delete

而不是：

bash 复制代码

PUT /orders/{id}
DELETE /orders/{id}

这背后其实有四个原因。

原因一：真实业务不是"资源操作"

REST 的假设是：

所有业务都可以抽象成资源。

但现实是：

很多业务是 行为（Action） 。

例如：

电商取消订单：

复制代码

取消订单

背后涉及：

修改订单状态
恢复库存
退款
发送消息
写审计日志

这已经不是

sql 复制代码

DELETE /order

这么简单。

所以很多公司设计成：

bash 复制代码

POST /orders/{id}/cancel

因为：

这是一个动作，不是删除资源。

原因二：软删除是常态

很多业务系统 几乎不会真正删除数据。

原因很简单：

需要：

审计
数据恢复
对账
风控

所以数据库通常会设计：

复制代码

is_deleted
deleted_at

删除订单其实是：

sql 复制代码

UPDATE order SET deleted = 1

所以 API 更像：

bash 复制代码

POST /orders/{id}/delete

而不是：

bash 复制代码

DELETE /orders/{id}

原因三：复杂业务需要批量操作

REST 的 DELETE 设计是：

bash 复制代码

DELETE /users/123

但企业系统经常需要：

复制代码

批量删除

例如：

复制代码

删除1000个用户

这时接口通常设计为：

arduino 复制代码

POST /users/batch-delete

请求体：

json 复制代码

{
  "userIds": [1,2,3,4]
}

DELETE 在这种场景就不太合适。

原因四：很多网关和客户端限制

历史上很多系统：

浏览器
表单
API 网关
负载均衡

对 HTTP 方法支持并不好。

例如：

HTML form 只支持：

sql 复制代码

GET
POST

很多早期系统为了兼容性：

全部使用 POST。

这个习惯延续到了今天。

PUT 的另一个问题 ------ 全量更新

PUT 的设计要求：

客户端提交完整资源

例如：

bash 复制代码

PUT /users/123

如果只想修改邮箱：

perl 复制代码

{
"email": "new@email.com"
}

但原数据是：

perl 复制代码

{
"name": "Alice",
"email": "old@email.com",
"age": 30
}

PUT 会导致：

复制代码

name 丢失
age 丢失

因此现代 API 更常用：

复制代码

PATCH

例如：

bash 复制代码

PATCH /users/123

perl 复制代码

{
"email": "new@email.com"
}

只更新字段。

- 03-

真正的大厂 API 其实是这样设计的

很多成熟系统会采用 混合策略：

标准资源操作

使用 REST：

bash 复制代码

GET /users/{id}
PUT /users/{id}
DELETE /users/{id}

业务行为

使用 POST：

bash 复制代码

POST /orders/{id}/cancel
POST /orders/{id}/refund
POST /orders/{id}/confirm

批量操作

bash 复制代码

POST /orders/batch-cancel
POST /users/batch-delete

部分更新

bash 复制代码

PATCH /users/{id}

换句话说：

REST 是基础，但不是枷锁。

工程实践通常是：

REST + Action API 混合设计

**-****04-**总结

PUT 和 DELETE 并没有被淘汰。

但在现代系统中：

很多业务并不是 资源操作 ，而是 业务行为。

所以越来越多 API 设计变成：

复制代码

POST + Action

例如：

bash 复制代码

POST /orders/{id}/cancel
POST /orders/{id}/refund

而不是：

bash 复制代码

DELETE /orders/{id}

真正成熟的 API 设计不是：

死守 REST

而是：

让接口既清晰，又符合业务语义。

复制代码