HTTP协议核心体系:请求方法与状态码全结构化解析
本文基于HTTP/1.1核心规范(RFC 7230-7235)及扩展规范,构建完整的HTTP请求方法、状态码知识体系,覆盖核心定义、分类规则、典型场景、规范约束与高频误区。
一、核心基础概念
1.1 HTTP方法的两大核心属性(规范级定义)
这是区分HTTP方法、规范使用的核心标尺,所有方法的设计均围绕这两个属性展开:
| 属性 |
RFC规范定义 |
核心意义 |
| 安全方法 |
方法执行不会修改服务器资源状态,仅为只读操作 |
客户端可重复发起,无任何业务风险,爬虫/缓存可自由访问 |
| 幂等方法 |
一次与多次重复执行相同请求,对服务器资源的副作用完全一致 |
分布式系统、重试场景的核心保障,避免重复提交导致的数据异常 |
关键误区纠正:幂等性不要求多次请求的响应码完全一致。例如DELETE请求,第一次返回204,第二次返回404,仍符合幂等性——因为多次请求的最终副作用都是「该资源被删除」,与单次执行一致。
1.2 HTTP状态码分类规则
HTTP状态码为3位数字,第一位数字定义响应类别,后两位为细分编码,共分为5大类,覆盖请求全生命周期的所有结果:
| 分类 |
核心含义 |
响应本质 |
| 1xx |
信息性状态码 |
请求已接收,正在处理,临时响应,需等待最终结果 |
| 2xx |
成功状态码 |
请求已被正常接收、理解、处理并完成 |
| 3xx |
重定向状态码 |
请求需客户端执行额外操作(跳转/缓存)才能完成 |
| 4xx |
客户端错误状态码 |
请求存在语法/语义/权限问题,服务端无法/拒绝处理 |
| 5xx |
服务端错误状态码 |
服务端处理请求时发生内部错误,无法完成合法请求 |
二、HTTP请求方法
2.1 标准核心方法(RFC 7231 定义)
2.1.1 只读类方法(安全+幂等)
| 方法 |
核心定义 |
典型使用场景 |
规范约束 |
高频误区 |
| GET |
获取目标资源的完整表示 |
页面加载、数据查询、接口拉取、搜索引擎爬虫 |
安全、幂等;仅支持URL传参,不应携带请求体 |
用GET执行修改/删除操作;用GET传输敏感数据;URL参数超限 |
| HEAD |
与GET完全一致,但服务端仅返回响应头,不返回响应体 |
资源可用性校验、大文件大小预检、接口连通性测试、缓存有效性验证 |
安全、幂等;绝对不能返回响应体 |
用于业务数据查询;返回响应体导致客户端解析异常 |
2.1.2 写入类方法(资源状态修改)
| 方法 |
核心定义 |
典型使用场景 |
安全/幂等 |
规范约束 |
核心区分 |
| POST |
让目标资源处理请求负载,执行非幂等的写入操作 |
新建资源、表单提交、文件上传、复杂查询(参数超GET限制) |
非安全、非幂等 |
重复提交会产生多个资源/多次副作用 |
唯一原生非幂等的标准写入方法,用于客户端不指定资源URI的创建 |
| PUT |
全量替换目标资源,用请求体的完整内容覆盖已有资源 |
全量更新已有资源、客户端指定URI的资源创建 |
非安全、幂等 |
请求必须携带资源的完整字段,多次提交结果完全一致 |
与POST核心区别:幂等性;与PATCH核心区别:全量替换vs增量修改 |
| DELETE |
删除指定的目标资源 |
资源删除、数据下线 |
非安全、幂等 |
多次删除的最终副作用一致(资源不存在) |
无需响应体,成功推荐返回204,资源不存在返回404 |
| PATCH |
增量更新目标资源,仅修改请求体指定的字段(RFC 5789扩展) |
资源部分字段更新、无需传输完整资源的场景 |
非安全、默认非幂等(可自定义实现幂等) |
请求体需描述增量修改规则,无需完整资源 |
解决PUT全量更新的带宽浪费问题,是RESTful接口的主流更新方案 |
2.1.3 控制类方法(协议通信管控)
| 方法 |
核心定义 |
典型使用场景 |
安全/幂等 |
规范约束 |
| OPTIONS |
获取目标资源支持的通信选项、允许的请求方法与权限 |
CORS跨域预检请求、服务端支持能力探测 |
安全、幂等 |
响应头需通过Allow字段返回资源支持的所有方法 |
| CONNECT |
与目标服务器建立TCP隧道,用于代理通信 |
HTTPS正向/反向代理、VPN隧道、加密流量转发 |
非安全、非幂等 |
仅用于代理场景,建立隧道后直接转发双向流量 |
| TRACE |
回显客户端的完整请求链路,用于通信诊断 |
代理链路调试、请求篡改检测、网络故障排查 |
安全、幂等 |
服务端需将收到的请求原封不动返回响应体,存在XST攻击风险,生产环境普遍禁用 |
2.2 方法核心特性速查表
| 方法 |
安全 |
幂等 |
可带请求体 |
推荐响应成功码 |
| GET |
✅ |
✅ |
不推荐 |
200 OK |
| HEAD |
✅ |
✅ |
❌ |
200 OK |
| POST |
❌ |
❌ |
✅ |
201 Created / 200 OK |
| PUT |
❌ |
✅ |
✅ |
200 OK / 204 No Content |
| PATCH |
❌ |
❌(默认) |
✅ |
200 OK / 204 No Content |
| DELETE |
❌ |
✅ |
不推荐 |
204 No Content |
| OPTIONS |
✅ |
✅ |
❌ |
200 OK |
| CONNECT |
❌ |
❌ |
❌ |
200 OK |
| TRACE |
✅ |
✅ |
❌ |
200 OK |
2.3 行业最佳实践
- 严格遵循幂等性规范:重试场景(如微服务超时重试、前端防重复提交)必须使用幂等方法,禁止用POST执行更新操作
- RESTful接口规范:资源创建用POST,全量更新用PUT,增量更新用PATCH,查询用GET,删除用DELETE
- 禁止方法滥用:不得用GET执行写入操作,不得用POST统一处理所有请求,避免破坏HTTP语义
- 安全约束:敏感数据绝对不能通过GET的URL参数传输,必须用POST/PUT的请求体加密传输
三、HTTP状态码(全分类与核心场景)
3.1 1xx 信息性状态码(临时响应)
仅HTTP/1.1及以上版本支持,为中间临时响应,无响应体,客户端收到后需继续等待最终响应。
| 状态码 |
名称 |
核心定义 |
典型使用场景 |
| 100 |
Continue |
服务端已接收请求头,允许客户端继续发送请求体 |
大文件/大请求体上传预检:客户端携带Expect: 100-continue头,服务端校验通过后返回100,避免客户端浪费带宽传输被拒绝的大文件 |
| 101 |
Switching Protocols |
服务端同意客户端的协议切换请求 |
WebSocket握手:客户端携带Upgrade: websocket头,服务端返回101,后续切换为WebSocket协议通信 |
| 103 |
Early Hints |
服务端提前返回响应头,告知客户端可预加载资源 |
前端性能优化:服务端处理HTML的同时,先通过Link头返回需要预加载的CSS/JS资源,让浏览器提前加载,减少白屏时间 |
| 102 |
Processing |
服务端已接收请求,正在处理中,暂无结果 |
WebDAV场景、耗时异步任务,避免客户端因长时间无响应触发超时 |
3.2 2xx 成功状态码(请求正常处理完成)
表示请求已被服务端完整处理,是唯一代表请求成功的分类。
| 状态码 |
名称 |
核心定义 |
典型使用场景 |
| 200 |
OK |
请求成功,服务端已正常处理并返回结果 |
GET查询成功、POST处理成功返回业务数据,是最通用的成功状态码 |
| 201 |
Created |
资源创建成功 |
POST/PUT创建资源成功(如用户注册、文件上传),响应头必须通过Location字段指向新资源的URI,响应体可携带创建的资源信息 |
| 202 |
Accepted |
请求已接收,但尚未处理完成 |
异步任务场景:批量数据处理、报表生成、视频转码,服务端接收任务后返回202,附带任务ID,客户端后续轮询任务进度 |
| 204 |
No Content |
请求成功,但无响应体 |
PUT全量更新、DELETE删除、PATCH增量更新成功,无需返回业务数据;前端无需处理响应体,仅需识别状态码 |
| 206 |
Partial Content |
部分内容请求成功 |
断点续传、分片下载、视频流媒体拖动播放,客户端携带Range头请求指定字节范围,服务端返回对应内容,响应头必须携带Content-Range说明返回范围与总大小 |
3.3 3xx 重定向状态码(需客户端额外操作)
核心分为3类:永久重定向、临时重定向、缓存重定向,核心区分点为「是否允许修改请求方法」「是否永久生效」「缓存策略」。
| 状态码 |
名称 |
核心定义 |
典型使用场景 |
关键约束 |
| 301 |
Moved Permanently |
资源永久移动到新URI |
网站域名更换、页面路径永久变更、SEO权重迁移 |
永久重定向,浏览器会长期缓存;允许客户端将POST请求改为GET |
| 308 |
Permanent Redirect |
资源永久移动到新URI |
需保持原请求方法的永久重定向场景 |
永久重定向,与301核心区别:绝对不允许修改请求方法,原POST请求必须仍以POST方式访问新地址 |
| 302 |
Found |
资源临时移动到新URI |
临时页面跳转、登录后跳回原页面 |
临时重定向,浏览器不缓存;允许客户端将POST请求改为GET(浏览器普遍实现) |
| 303 |
See Other |
请求已处理,需用GET方法获取新资源 |
POST表单提交成功后,跳转到结果页面,避免用户刷新页面重复提交表单 |
临时重定向,无论原请求是什么方法,必须用GET方式访问重定向地址 |
| 307 |
Temporary Redirect |
资源临时移动到新URI |
需保持原请求方法的临时重定向场景(如表单POST提交跳转) |
临时重定向,与302核心区别:绝对不允许修改请求方法,原POST请求必须仍以POST方式访问新地址 |
| 304 |
Not Modified |
资源未修改,无需重新传输 |
HTTP协商缓存:客户端携带If-Modified-Since/If-None-Match头,服务端验证资源未更新,返回304,客户端直接使用本地缓存 |
无响应体,必须配合Cache-Control/ETag/Last-Modified缓存头使用,是前端性能优化的核心机制 |
3.4 4xx 客户端错误状态码(请求存在问题)
表示请求本身存在错误,服务端无法或拒绝处理,责任在客户端,重复提交相同请求仍会失败。
| 状态码 |
名称 |
核心定义 |
典型使用场景 |
关键区分 |
| 400 |
Bad Request |
请求语法错误、参数无效,服务端无法理解 |
请求体JSON格式错误、必填参数缺失、参数类型不匹配、URL编码错误 |
通用客户端语法错误,针对请求格式本身 |
| 401 |
Unauthorized |
请求需要用户身份认证,未认证或认证失效 |
未登录访问需要登录的接口、Token过期/无效 |
核心是「未认证」,响应头必须携带WWW-Authenticate字段说明认证方式;与403的核心区别:用户身份未被服务端识别 |
| 403 |
Forbidden |
服务端已识别用户身份,但拒绝执行请求 |
普通用户访问管理员接口、IP被封禁、CSRF令牌无效、资源访问权限不足 |
核心是「已认证但无权限」,服务端明确拒绝提供服务,重复提交无效 |
| 404 |
Not Found |
请求的资源不存在 |
URL输入错误、资源已删除、接口路径写错、路由未配置 |
最通用的资源不存在错误,不说明资源是临时还是永久消失 |
| 405 |
Method Not Allowed |
请求方法不被目标资源支持 |
资源仅支持GET请求,客户端使用了POST/PUT方法 |
响应头必须通过Allow字段返回该资源支持的所有请求方法 |
| 409 |
Conflict |
请求与资源的当前状态存在冲突 |
并发修改资源、注册时手机号已存在、唯一约束重复、资源版本冲突 |
需客户端解决冲突后重新提交请求,针对业务逻辑层面的冲突 |
| 410 |
Gone |
资源已永久删除,不会再恢复 |
资源被永久下线、旧版本接口永久停用 |
比404更明确,搜索引擎会删除该资源的索引 |
| 413 |
Payload Too Large |
请求体大小超过服务端限制 |
上传文件超过服务端最大大小限制、POST请求体过大 |
服务端可携带Retry-After头,告知客户端重试时间 |
| 415 |
Unsupported Media Type |
请求的媒体类型不被服务端支持 |
请求体Content-Type为application/xml,但服务端仅接受application/json |
针对请求体的格式类型,而非语法错误 |
| 422 |
Unprocessable Entity |
请求格式正确,但语义无法处理 |
参数格式符合要求,但业务校验失败:密码长度不足、手机号格式正确但已被注册、字段值超出业务范围 |
RESTful接口主流业务错误码,与400核心区别:400是语法错误,422是语义/业务逻辑错误 |
| 429 |
Too Many Requests |
客户端请求次数过多,触发服务端限流 |
接口防刷、爬虫拦截、API网关限流、单用户请求频率超限 |
响应头可携带Retry-After头、限流规则说明,是微服务高可用防护的核心状态码 |
3.5 5xx 服务端错误状态码(服务端处理失败)
表示服务端在处理合法请求时发生了内部错误,责任在服务端,请求本身无问题,后续重试可能成功。
| 状态码 |
名称 |
核心定义 |
典型使用场景 |
关键区分 |
| 500 |
Internal Server Error |
服务端发生未知内部错误,无法完成请求 |
代码运行异常(空指针、数组越界)、数据库执行报错、服务配置错误、依赖服务崩溃 |
最通用的服务端错误码,用于未分类的内部异常 |
| 501 |
Not Implemented |
服务端不支持请求的方法,无法完成处理 |
客户端使用了服务端未实现的扩展方法、未兼容的HTTP协议特性 |
与405核心区别:405是方法存在但不被该资源支持,501是服务端根本不支持该方法 |
| 502 |
Bad Gateway |
网关/代理服务器收到上游服务的无效响应 |
Nginx反向代理场景:上游Tomcat/Node服务崩溃、上游服务重启、上游服务返回了无法解析的无效响应 |
核心是「上游服务不可达/返回无效响应」,网关能正常工作 |
| 503 |
Service Unavailable |
服务端暂时不可用 |
服务停机维护、服务过载熔断、服务器资源耗尽、流量峰值限流 |
是临时不可用,响应头可携带Retry-After头告知恢复时间,监控系统可基于此做告警 |
| 504 |
Gateway Timeout |
网关/代理服务器请求上游服务超时 |
Nginx反向代理场景:上游服务处理耗时过长、SQL慢查询、依赖服务调用超时,超过了网关的超时阈值 |
与502核心区别:502是上游服务不可达,504是上游服务能连通,但响应超时 |
| 505 |
HTTP Version Not Supported |
服务端不支持客户端使用的HTTP协议版本 |
客户端使用HTTP/3发起请求,但服务端仅支持HTTP/1.1 |
四、高频易错点与规范红线
- 幂等性红线:重试场景、支付/订单等核心业务,必须使用幂等方法,禁止用POST执行更新操作,避免重复扣款、重复下单
- 状态码语义滥用:禁止用200统一返回所有结果(包括业务错误),否则会破坏HTTP语义,导致监控、CDN、网关无法正确识别请求结果
- 核心状态码混淆:
- 401=未登录/未认证,403=已登录但无权限,不可混用
- 301/302允许修改请求方法,308/307禁止修改,表单POST跳转必须用307/308,避免表单数据丢失
- 502=上游服务挂了,504=上游服务响应超时,不可混用
- 重定向缓存坑:301是永久重定向,会被浏览器长期缓存,临时跳转绝对不能使用301,否则会导致用户无法访问原地址
- 方法语义滥用:禁止用GET执行删除/修改操作,禁止用POST统一处理所有请求,避免破坏HTTP的缓存、安全、幂等性设计
五、RESTful接口方法与状态码协同规范
| 请求方法 |
业务场景 |
成功响应码 |
常见错误响应码 |
| GET |
查询单个/列表资源 |
200 OK |
404(资源不存在)、401(未登录)、403(无权限) |
| POST |
创建新资源 |
201 Created |
400(参数格式错误)、422(业务校验失败)、409(资源冲突)、401/403 |
| PUT |
全量更新资源 |
200 OK / 204 No Content |
404(资源不存在)、400/422(参数错误)、401/403 |
| PATCH |
增量更新资源 |
200 OK / 204 No Content |
404(资源不存在)、400/422(参数错误)、401/403 |
| DELETE |
删除资源 |
204 No Content |
404(资源不存在)、403(无权限)、401(未登录) |
附:思维导图
