做接口设计、前后端联调或 RESTful API 开发时，HTTP 请求方法是 “接口的灵魂”—— 列如 GET 用于查数据、POST 用于传表单、PUT 用于全量更新、DELETE 用于删资源，用错方法不仅会导致逻辑混乱，还可能引发安全风险（如用 GET 传密码）。但许多开发者只熟悉 GET/POST，对 PUT/PATCH/OPTIONS 等方法的用法和标准特性一知半解，甚至把 “所有请求都用 POST”，导致接口设计不规范。

今天整理完整 HTTP 请求方法体系，按 “核心 CRUD 方法（高频）→辅助诊断方法（排错）→特殊用途方法（少见）” 三大类拆解 15 种方法，重点讲透 9 种常用方法的 “核心定义 + HTTP 标准特性 + 高频场景 + 避坑技巧”，穿插 2 个实战案例（RESTful API 设计踩坑、GET 传敏感数据的风险），文末有 “场景速查表”，按Ctrl+F可快速定位目标方法，收藏这篇，接口设计不用再 “瞎用 POST”！

一、先搞懂：HTTP 请求方法的 2 个核心标准特性（避免用错）

在看具体方法前，先明确 HTTP 标准对请求方法的 2 个关键定义，这是判断 “方法用得对不对” 的核心依据：

1.幂等性（Idempotency）

多次调用同一方法，产生的结果一样（不会因调用次数多而出现不同效果）。

幂等方法：GET（查数据，多次查结果一样）、PUT（全量更新，多次更结果一样）、DELETE（删资源，删 1 次和删 10 次结果一样）；
非幂等方法：POST（提交表单，多次提交会创建多个资源，如重复下单）。

关键作用：幂等方法可重试（如网络波动时重发请求），非幂等方法重试需防重复（如加唯一订单号）。

2.安全性（Safety）

调用方法不会 “修改服务器资源”，仅用于 “获取信息”。

安全方法：GET（查数据）、HEAD（仅获响应头）、OPTIONS（查服务器支持的方法）；
非安全方法：POST（创资源）、PUT（改资源）、DELETE（删资源）（会改服务器数据）。

关键作用：安全方法可被缓存（如 GET 请求结果存浏览器缓存），非安全方法缓存需谨慎。

二、按实用优先级拆解：15 种方法 + 场景避坑

（一）核心 CRUD 方法（高频用，覆盖 80% 接口场景）

这类方法对应 “增删改查”（CRUD）核心需求，是 RESTful API 和日常接口设计的基础，重点记 6 种：

方法	核心定义（HTTP 标准）	高频场景	避坑 / 实操技巧
GET	从服务器获取指定资源，请求参数附在 URL 后	查列表（/api/users）、查详情（/api/users/123）、搜索（/api/users?name=张三）	避坑 1：不要用 GET 传敏感数据（密码、Token），URL 会被日志记录，泄露风险；避坑 2：URL 长度有限制（不同浏览器 / 服务器上限不同，一般 2-8KB），大参数（如长搜索条件）改用 POST；实操：GET 请求可被缓存（如浏览器存静态资源请求结果），适合不常变的查询。
POST	向服务器提交数据，请求体存参数，可创建 / 修改资源	提交表单（登录、注册）、上传文件、创建资源（/api/articles）、复杂查询（大参数）	避坑 1：非幂等，多次提交会重复创建（如重复下单），需加唯一标识（如订单号）防重；避坑 2：不要把 “查询” 用 POST（如POST /api/users/query），查询应优先用 GET，符合 HTTP 语义；实操：请求体支持任意格式（JSON、表单、文件），无大小限制（服务器可配置）。
PUT	全量更新服务器资源（覆盖式更新），需传完整资源数据	全量改用户信息（PUT /api/users/123，需传所有用户字段：姓名 / 年龄 / 手机号，缺字段会被置空）	避坑 1：幂等，多次调用结果一样（如多次传一样用户数据，服务器仅更新 1 次），可重试；避坑 2：区别于 PATCH（全量 vs 部分更新），列如改用户手机号，PUT 需传 “姓名 + 年龄 + 新手机号”（全量），PATCH 仅传 “新手机号”（部分）；实操：RESTful API 中，PUT 对应 “更新资源”，URL 需指定具体资源 ID（如/api/users/123）。
DELETE	请求服务器删除指定资源	删用户（DELETE /api/users/123）、删文章（DELETE /api/articles/456）	避坑 1：幂等，但需注意 “删后再删” 的处理（如第一次删返回 204，第二次删返回 404，仍符合幂等性，因结果都是 “资源不存在”）；避坑 2：敏感删除操作需加权限校验（如仅管理员能删用户），避免恶意删除；实操：响应一般返回 204（无内容）或 200（带删除成功信息）。
PATCH	部分更新服务器资源（仅传要修改的字段）	局部改用户信息（PATCH /api/users/123，仅传 “手机号 = 138xxxx8888”，其他字段不变）	避坑 1：幂等，但需确保 “部分更新逻辑正确”（如仅改手机号，不会把姓名置空）；避坑 2：部分服务器 / 框架对 PATCH 支持不完善（如早期 Spring MVC 需额外配置），兼容问题可改用 PUT 传全量字段；实操：请求体提议用 JSON 格式，明确要修改的字段（如{“phone”: “138xxxx8888”}）。
HEAD	与 GET 一致，但仅返回响应头，无响应体	查资源是否存在（如查图片是否存在，仅看响应码 200/404）、查资源大小（读Content-Length头）	避坑：不要用 HEAD 获取 “需要响应体的数据”（如用户详情），它仅用于 “轻量检查”；实操：比 GET 更省带宽（无响应体），适合批量检查资源状态（如爬虫查一批 URL 是否有效）。

（二）辅助诊断方法（排错用，解决接口调试问题）

这类方法不处理业务逻辑，主要用于 “接口诊断”“服务器能力探测”，重点记 3 种：

方法	核心定义（HTTP 标准）	高频场景	避坑 / 实操技巧
OPTIONS	查看服务器对指定 URL 支持的 HTTP 请求方法	接口调试（如查/api/users支持 GET/POST/PUT 吗）、跨域预检（CORS 预检请求默认用 OPTIONS）	避坑 1：跨域场景下，浏览器会先发 OPTIONS 预检请求，服务器需返回 Access-Control-Allow-Methods头（如GET,POST,PUT），否则跨域请求失败；实操：用 curl 测试：curl -X OPTIONS -i https://example.com/api/users，响应头Allow会列出支持的方法。
TRACE	回显服务器收到的请求，用于诊断请求链路	排查 “请求是否被代理修改”（如查请求头是否被网关篡改）	避坑 1：安全风险，可能泄露请求头信息（如 Cookie、Token），生产环境提议禁用；避坑 2：大部分服务器默认关闭 TRACE（如 Nginx 需手动配置开启），不要依赖它做常规调试；实操：用 curl 测试：curl -X TRACE https://example.com，响应体会显示完整请求内容。
CONNECT	将 HTTP 连接转为隧道连接，用于代理服务器（如 HTTPS 代理）	通过代理访问 HTTPS 网站（如浏览器配置代理后，访问https://baidu.com会发 CONNECT 请求给代理）	避坑 1：仅用于代理场景，普通接口不要用；避坑 2：生产环境代理需限制 CONNECT 的目标地址，防止被用于翻墙或攻击；实操：代理服务器收到 CONNECT 请求后，会与目标服务器建立 TCP 连接，再转发数据（实现 “隧道” 功能）。

（三）特殊用途方法（少见用，仅特定场景适用）

这类方法是 HTTP 标准定义的扩展方法，日常开发中很少用到，了解即可，共 6 种：

方法	核心定义（HTTP 标准）	适用场景	注意事项
MOVE	请求服务器将指定资源 “移动” 到新 URL（类似文件移动）	服务器端资源整理（如MOVE /old/path到/new/path）	大部分 Web 服务器（如 Nginx、Apache）默认不支持，需自定义实现；替代方案：实际开发中常用 “先复制（COPY）再删除（DELETE）” 模拟移动
COPY	请求服务器将指定资源 “复制” 到新 URL	服务器端资源复制（如COPY /source/path到/target/path）	同 MOVE，需服务器自定义支持，日常开发少用；注意：复制后新旧资源独立，修改其中一个不影响另一个
LINK	建立资源间的 “链接关系”（如 A 资源关联 B 资源）	文档关联（如一篇文章关联多个标签资源）	HTTP 标准未明确链接的具体格式，不同服务器实现差异大，兼容性差；替代方案：用数据库外键（如文章表存标签 ID）实现关联，更易维护
UNLINK	断开资源间的链接关系（LINK 的反向操作）	撤销文档关联（如文章移除某个标签）	同 LINK，需配合 LINK 使用，少用；注意：仅断开链接，不删除资源本身
WRAPPED	允许客户端发送 “封装后的请求”（如嵌套请求）	复杂协议扩展（如 SOAP 协议基于 HTTP 的封装）	非 HTTP 1.1 标准方法，是扩展提案，几乎没有主流服务器支持；现状：已被更成熟的协议（如 REST、GraphQL）替代，无需关注
Extension-method	自定义扩展方法（在不修改 HTTP 协议的前提下新增）	企业私有协议（如某公司自定义PURGE方法用于清除缓存）	注意：自定义方法需确保客户端和服务器都支持，否则会返回 405（方法不允许）；示例：Nginx 支持PURGE方法清除缓存（需配置），但非 HTTP 标准

三、实战案例：2 个常见问题用请求方法解决

案例 1：RESTful API 设计踩坑（PUT vs PATCH 用错导致数据丢失）

问题：前端调用PUT /api/users/123更新用户手机号，仅传了{“phone”: “138xxxx8888”}，后端用 PUT 接口接收，因 PUT 是 “全量更新”，把未传的 “姓名、年龄” 字段置空，导致用户数据丢失。

缘由：混淆 PUT 和 PATCH 的语义 ——PUT 需传全量字段，PATCH 仅传部分字段，前端用 PUT 传部分字段，后端未做兼容处理。

解决：1. 若用 PUT，前端需传全量字段（{“name”: “张三”, “age”: 25, “phone”: “138xxxx8888”}）；2. 若仅传部分字段，改用 PATCH 方法（PATCH /api/users/123），后端接口按 “部分更新” 逻辑处理，只改传了的字段。

案例 2：GET 传敏感数据导致安全风险

问题：前端用GET /api/login?username=zhangsan&password=123456提交登录请求，服务器日志记录了完整 URL，导致密码泄露。

缘由：违反 GET 的 “安全性” 语义 ——GET 是安全方法，用于获取信息，不应传敏感数据（密码、Token），且 URL 会被日志、浏览器历史记录保存。

解决：1. 登录请求改用 POST 方法，密码放在请求体（如 JSON 格式：{“username”: “zhangsan”, “password”: “123456”}）；2. 生产环境开启 HTTPS，加密传输数据（即使 POST，也需 HTTPS 防中间人窃取）；3. 服务器日志过滤敏感字段（如密码、Token），避免记录。

四、HTTP 请求方法场景速查表（Ctrl+F 快速找）

业务需求	推荐方法	关键注意点
查列表 / 详情 / 搜索（无敏感数据，参数小）	GET	不传敏感数据，参数放 URL，可缓存
登录 / 注册 / 提交表单（有敏感数据，参数大）	POST	非幂等，需防重复提交，参数放请求体
上传文件 / 复杂查询（大参数）	POST	请求体无大小限制，支持二进制数据
全量更新资源（传所有字段）	PUT	幂等，URL 需指定资源 ID，可重试
部分更新资源（传部分字段）	PATCH	幂等，兼容问题可改用 PUT 传全量字段
删除资源	DELETE	幂等，需权限校验，删后再删返回 404
检查资源是否存在（轻量验证）	HEAD	仅返回响应头，省带宽，不查响应体
查服务器支持的方法 / 跨域预检	OPTIONS	跨域场景浏览器会自动发预检请求
代理访问 HTTPS 网站	CONNECT	仅用于代理隧道，普通接口不用

总结：用好请求方法的 3 个核心原则

遵循 HTTP 语义：不要 “所有请求都用 POST”，查用 GET、创用 POST、全量改用 PUT、部分改用 PATCH、删用 DELETE，符合语义的接口更易维护和调试；
关注幂等性和安全性：幂等方法（GET/PUT/DELETE）可重试，非幂等方法（POST）需防重复；安全方法（GET/HEAD）可缓存，非安全方法（POST/PUT/DELETE）需谨慎缓存；
规避安全风险：GET 不传敏感数据，POST 用 HTTPS，生产环境禁用危险方法（如 TRACE），自定义方法需做权限控制。

你在接口设计中遇到过请求方法用错的问题吗？评论区聊聊你的踩坑经历，一起避坑～

文章版权归作者所有，未经允许请勿转载。如内容涉嫌侵权，请在本页底部进入<联系我们>进行举报投诉!

THE END