Author: Cyan_RA9
Source: 【卡码笔记】网站
Question: HTTP请求方式有哪些？
【简要回答】
- HTTP/1.1 最初定义了 8种核心请求方法（RFC 2616, 1999）：
- GET：获取资源，参数在URL中，对于服务器安全，且幂等。
- POST：提交数据（如表单数据），可能修改服务器状态。
- PUT：全量更新资源，幂等。
- DELETE：删除资源，幂等。
- HEAD：类似GET，仅返回响应头。
- OPTIONS：查询服务器支持的请求方法。
- TRACE：回显请求（因安全风险通常禁用）。
- CONNECT：建立代理隧道（如HTTPS）。
- 注意事项：
- PATCH 是后续通过 RFC 5789（2010）添加的扩展方法，不属于 HTTP/1.1 最初定义的方法。
【详细回答】
HTTP/1.1 最初定义的 8种核心请求方法
- GET：
- 作用：请求指定资源，参数通过URL传递。
- 特点：安全（不修改服务器资源）、幂等（多次请求结果一致）、可缓存（响应可被浏览器或代理缓存）。
- 场景：数据查询、页面加载。
- POST：
- 作用：提交数据（通过请求体携带数据）。
- 特点：不安全（可能修改服务器状态，eg: 新增订单）、不幂等（重复提交可能产生不同结果，eg: 多次创建订单）。
- 场景：表单提交、触发业务逻辑。
- PUT：
- 作用：全量更新资源（客户端需提供完整数据）。
- 特点：幂等（多次更新结果一致，如重复更新同一资源）、不安全（可能覆盖其他用户的修改）。
- 场景：用户信息全量更新。
- DELETE：
- 作用：删除指定资源。
- 特点：幂等（多次删除同一资源效果相同，如资源不存在时返回相同状态）、不安全（直接修改服务器状态）。
- 场景：删除文章、用户等资源。
- HEAD：
- 作用：与GET类似，但服务器不返回响应体，仅返回响应头。
- 特点：轻量（节省带宽，用于检查资源是否存在或是否更新，如Last-Modified）、安全、幂等。
- 场景：检查资源是否存在或更新，eg: 验证链接有效性、资源缓存状态。
- OPTIONS：
- 作用：查询服务器支持的请求方法，或检查跨域请求权限。
- 特点：预检请求：浏览器自动发送OPTIONS请求进行CORS验证。
- 场景：跨域API调用前的预检请求。
- TRACE：
- 作用：回显客户端请求（用于调试）。
- 特点：易引发安全风险（如XST攻击），通常禁用。
- CONNECT：
- 作用：建立代理隧道（如HTTPS）。
- 特点：由服务器/代理处理，不直接暴露给业务层。
扩展方法（非HTTP/1.1原生）
- PATCH：
- 说明：来自RFC 5789（2010），注意，RFC 5789（2010）是独立扩展规范，仅新增PATCH方法，需显式支持，不涉及HTTP版本更新。
- 作用：局部更新资源，需定义数据格式（如JSON Patch），客户端仅提交需修改的字段。
- 特点：非幂等（多次局部更新可能导致不同结果）、灵活（需定义数据格式）。
- 场景：修改用户的部分信息（如昵称）。
【知识拓展】
HTTP请求方式的发展历程
- As the following picture:
为什么 HttpServlet 源码中只定义了七种方法？
- HttpServlet 基于 HTTP/1.1（RFC 2616, 1999） 设计，而 原始规范RFC 2616 定义的8种方法中，
TRACE和CONNECT默认不推荐开发者直接使用，原因如下：TRACE因安全风险（如XST攻击）通常被禁用。CONNECT由服务器底层（如Tomcat）处理，无需业务代码干预。
- 因此，HttpServlet仅暴露了 GET、POST、PUT、DELETE、HEAD、OPTIONS 这6个常用方法，加上
TRACE共7种。
不同HTTP版本支持的请求方法
- HTTP/1.0（RFC 1945, 1996）：GET、POST、HEAD。
- HTTP/1.1（RFC 2616, 1999）：GET、POST、PUT、DELETE、HEAD、OPTIONS、TRACE、CONNECT。
- HTTP/1.1（RFC 7231, 2014）：同 RFC 2616（1999），目前HTTP/1.1的核心规范。
- HTTP/2（RFC 7540, 2015）：兼容HTTP/1.1方法，未新增。
- HTTP/3（RFC 9114, 2022）：同样兼容，未新增方法。
