200 是什么
200 OK 是最通用的成功响应：请求已被服务器处理，响应体（如果有）就是对请求的正常结果。RFC 9110 §15.3.1 只把它定义为通用成功，不区分是读取、创建还是修改。因此 REST 实践中更推荐把精确语义交给 201、202、204 承担：全部堆在 200 上，短期看不出问题，长期会让监控、缓存与重试策略失去判断依据。
基本信息
| 名称 | 200 OK（RFC 9110 §15.3.1） |
|---|---|
| 作用 | 通用成功，最常用的成功响应 |
| 常见于 | 读取资源、提交后返回处理结果 |
| 响应体 | 可以有也可以没有，取决于业务 |
| 何时不用 | 创建用 201、异步受理用 202、无内容用 204 |
典型使用场景
- 读取接口数据：返回列表或详情的正常结果
- 提交后同步返回处理结果：登录、搜索、简单更新
- 静态资源访问成功：页面、图片、脚本的常规响应
- 幂等更新完成：替换成功但业务上不需要给出新地址
- 第三方回调确认：对方推送后回一个成功信号
读取接口并核对状态
读取接口并核对状态
curl -s -w '\nHTTP %{http_code}\n' https://api.example.com/users/101 # 打印响应体与状态码
curl -si https://api.example.com/users/101 | head -12 # 连响应头一起看，确认内容类型与缓存策略
curl -s -o /dev/null -w '%{http_code}\n' https://api.example.com/health # 健康检查只取状态码成功码怎么分工
| 场景 | 推荐码 | 关键点 |
|---|---|---|
| 读取到内容 | 200 | 带上正确的媒体类型 |
| 创建了新资源 | 201 | 用地址头指出新资源位置 |
| 异步受理，结果未定 | 202 | 给出进度查询地址 |
| 成功但没有内容可返回 | 204 | 不得携带响应体 |
| 资源未变化，用本地缓存 | 304 | 属于重定向类，不是成功类 |
让错误不再伪装成成功
让错误不再伪装成成功
# 反例：HTTP 200，响应体里塞业务错误码
# {"code":5001,"msg":"库存不足"}
# 正确做法：业务错误用 4xx，并给出机器可读的错误标识
curl -si -X POST https://api.example.com/orders -H 'Content-Type: application/json' -d '{}' # 应返回 400 或 409缓存排障时要把成功与未修改分开看：返回 200 说明取回了完整内容，返回 304 说明命中了协商缓存；两者是完全不同的链路，混在一起分析会得出错误结论。
把业务失败也返回 200、只在响应体里给错误码，会让网关、监控、重试与浏览器缓存全部失去判断依据：统计口径看不到失败量，客户端无法自动重试，压测也测不出瓶颈。
客户端分支怎么写
- 按首位数字判断类别而不是逐个码硬编码，否则服务端新增一个码就会走进未知分支
- 读到成功且无内容的状态码时不要去解析响应体，否则会抛出解析异常
- 读到异步受理的状态码时进入轮询流程，不要当作已经完成
- 读到限流的状态码时按提示的等待时间退避，立刻重试只会加重限流
- 对成功但内容为空的响应要做兜底，避免前端把空数据渲染成报错页
成功响应该带哪些头
| 头部 | 作用 |
|---|---|
| 内容类型与字符集 | 决定客户端按什么格式解析响应体 |
| 缓存策略 | 决定该响应能被复用多久、要不要回源验证 |
| 位置头 | 创建成功时指出新资源的地址 |
| 响应长度 | 便于客户端判断内容是否收全 |
健康检查要接受整段成功码
健康检查要接受整段成功码
# 只把 200 当成功，会在服务改成无内容响应时误报故障
code=$(curl -s -o /dev/null -w '%{http_code}' https://api.example.com/health)
case "$code" in
2??) echo 正常 ;; # 整段成功码都算健康
*) echo 异常: $code ;;
esac与其他成功码的取舍
- 已经创建过的资源被重复提交时返回成功还是冲突，取决于业务是否要求调用方感知重复
- 批量操作只部分成功时不要统一回一个成功码，应在响应体里逐条给出每个元素的结果
- 没有内容可返回的操作优先用无内容码，省掉客户端对空响应体的解析分支