 

刚学 REST API 的时候，我们都被教过一套“标准答案”：

- `GET` 查数据
- `POST` 创建数据
- `PUT` 更新数据
- `DELETE` 删除数据

多整齐。多漂亮。多符合 REST 原则。

但是，如果你去翻 Google Cloud、Azure、AWS 的 API 文档，你会发现一个有趣的现象：**它们大量使用 GET 和 POST，却很少用 PUT 和 DELETE。**

难道大厂工程师都不懂 REST？

恰恰相反——他们太懂了，所以知道什么时候该“不按规矩来”。

---

## 教科书里的 REST：世界很美好

刚学 REST 的时候，我们设计接口是这样的：

```
GET    /users/123    → 查询用户
POST   /users        → 创建用户
PUT    /users/123    → 更新用户
DELETE /users/123    → 删除用户
```

完美。简洁。一目了然。

如果所有系统都只是一个简单的数据库，这套设计确实够用了。

但现实是：

**大型互联网系统不是数据库的简单映射，而是一堆复杂的业务流程。**

---

## 大厂面对的是“业务”，不是 CRUD

小项目里，删除就是：

```sql
DELETE FROM user WHERE id = 123;
```

但 Google、微软这种体量的系统里，一个对象背后挂着一大堆东西：

- 权限系统
- 审计日志
- 缓存
- 消息队列
- 搜索索引
- 风控系统
- 计费系统
- 合规系统

比如删除一个云虚拟机：

```
DELETE /virtualMachines/vm001
```

表面看是“删掉一台机器”。但实际要做的可能是：

1. 停止计算节点
2. 回收 IP 地址
3. 清理关联磁盘
4. 更新计费系统
5. 写审计日志
6. 通知监控系统
7. 更新控制面板状态

这已经不是“删除”了，这是一个包含多个步骤的**业务流程**。

所以很多大厂的 API 长这样：

```
POST /virtualMachines/vm001/delete
```

而不是：

```
DELETE /virtualMachines/vm001
```

为什么？因为 `POST` 的语义更像**“请服务器执行一个操作”**，而不是简单的“删掉这条数据”。

---

## DELETE 的最大问题：不可逆

“DELETE”这个名字太吓人了。

看到：

```
DELETE /customer/123
```

工程师第一反应是：**完蛋，这东西没了。**

但真实业务里，几乎没有真正的“物理删除”。

比如你“删除”Google Drive 里的文件，它其实只是进了垃圾箱，30 天后才真正清理。数据库里可能只是：

```sql
UPDATE files SET deleted = true;
```

所以 API 设计成：

```
POST /files/123/trash
```

语义上更准确：**“移动文件到回收站”**，而不是“把它从世界上抹掉”。
 真正的数据库里，几乎没有物理删除
刚入行的新手可能觉得“删除就是 DELETE FROM”。但现实是：

重要的业务数据，几乎不会真的被删掉。

大多数系统的订单表里，都有一个 deleted_at 或 is_deleted 字段。所谓的“删除”，不过是一条 UPDATE：

sql
UPDATE orders SET status = 'CANCELLED', cancelled_at = NOW();
为什么要“假删除”？

需要审计追踪

需要财务对账

需要客服查历史订单

需要合规要求（金融数据至少保留 5 年）

需要恢复误删的数据

资源还在，只是状态变了。所以用 DELETE 来表达“删除”业务，本身就是错误的。更准确的说法是“将订单标记为已取消”

典型的数据库的软删除设计一般都会出现如下的字段

```bash
is_deleted
deleted_at
deleted_by
```

---

## PUT 的最大问题：太理想化了

REST 里 `PUT` 的语义是**“用新的资源完整替换旧的”**。

比如原来的用户是：

```json
{
  "name": "Tom",
  "age": 20,
  "city": "NY"
}
```

你发一个 `PUT`：

```json
{
  "name": "Tom",
  "age": 21
}
```

按照严格 REST 标准，结果应该是：

```json
{
  "name": "Tom",
  "age": 21
}
```

`city` 没了。因为 PUT 是**全量替换**。

但在实际开发中，前端经常只是想“改个年龄”，不想管其他字段。

于是大家更愿意用 `PATCH`：

```json
PATCH /users/123
{
  "age": 21
}
```

只改需要改的，别的别碰。

但 `PATCH` 的实现又不统一——有的用 JSON Patch，有的用 Merge Patch，各有各的格式。最后很多团队心想：

> 算了，直接用 `POST /users/123/update` 更省事。

---

## POST 为什么这么受欢迎？

因为 `POST` 是 HTTP 世界里的“万能钥匙”。

它的语义就是：**“把这事交给服务器处理。”**

- 创建资源：`POST /users`
- 执行动作：`POST /payment/pay`
- 触发任务：`POST /backup/start`
- 状态变更：`POST /account/disable`
- 复杂查询：`POST /search`

现代系统里，越来越多的操作是**命令（Command）**驱动的，而不是简单的资源 CRUD。

---

## 大厂真正关心的是什么？

作为架构师，设计 API 时考虑的优先级往往是：

### 1. 稳定性和兼容性

一个 API 可能要活 5-10 年。今天设计得再漂亮，明天业务变了怎么办？

`POST` 的扩展性更强，加字段不影响旧调用。而 `DELETE` 一旦上线，基本不敢改语义。

### 2. 安全性

`DELETE` 天然容易误操作。

```
DELETE /database/prod
```

配置错一个环境变量，生产数据就没了。

所以很多企业会强制要求加上确认：

```
POST /database/prod/delete
{
  "confirm": "YES",
  "reason": "maintenance"
}
```

### 3. 跨协议兼容

现实世界里有防火墙、CDN、老代理、企业网关……很多环境对 `DELETE` 和 `PUT` 的支持并不好，但 `GET` 和 `POST` 通行无阻。

---

## REST 是图纸，而大厂在地震带上盖楼

REST 是一份漂亮的建筑蓝图。

但 Google、微软这些公司是在地震带上盖摩天大楼——他们必须考虑：

- 怎么防止误操作？
- 怎么支撑十年演进？
- 怎么应对复杂业务流程？
- 怎么兼容各种网络环境？

所以他们的 API 设计越来越像：

> **“HTTP 外壳 + RPC 内核”**

资源用 `GET` 读，动作用 `POST` 做。

---

## 那是不是 REST 就过时了？

当然不是。

如果你的系统是：

- 简单 CRUD 应用
- 后台管理系统
- 小型 SaaS
- 数据模型稳定

标准 REST 完全够用：

```
GET /products
POST /products
PATCH /products/1
DELETE /products/1
```

但是，如果你的系统是：

- 云平台
- 金融系统
- 大规模 SaaS
- 分布式系统
- 异步任务处理

**动作模型往往比资源模型更贴近现实。**

```
POST /orders/123/cancel
POST /vm/123/start
POST /payment/refund
```

---

## 总结

REST 不是法律，是设计哲学。

大厂不是“不懂 REST”，而是经历过无数次生产事故后，选择了更务实的方式。

> **GET 用来读世界，POST 用来改变世界。**

这就是为什么你看到的云 API，越来越像 RPC 披着 HTTP 的外衣。

但是，如果你去翻 Google Cloud、Azure、AWS 的 API 文档，你会发现一个有趣的现象：它们大量使用 GET 和 POST，却很少用 PUT 和 DELETE。

为什么大厂 API 不爱用 PUT 和 DELETE？真相是。。。

后端

架构设计

网络与通信

大厂API弃用PUT/DELETE，并非不懂REST，而是为应对复杂业务、数据安全与长期稳定。POST语义灵活，可承载不可逆操作、软删除及多步骤流程，扩展性强，更适配现实场景。简单CRUD仍用标准REST，但云平台等复杂系统，则倾向“HTTP外壳+RPC内核”的务实设计。

消息队列

代码解释

数据库

服务器

虚拟机

防火墙

SaaS

CDN免费试用


2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

为什么大厂 API 不爱用 PUT 和 DELETE？真相是。。。-腾讯云开发者社区-腾讯云

为什么大厂 API 不爱用 PUT 和 DELETE？真相是。。。

为什么大厂 API 不爱用 PUT 和 DELETE？真相是。。。

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐