本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
【腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
程序员又来需求了，这样的需求多来一打，会不会增加一些工作岗位呢？不好说，说不定新需求来了 AI 也更更聪明了。
最近，我看到 IETF 正式发布了 RFC 10008，这个提案为 Http 新增了一个 QUERY 方法，为 REST API 设计迎来了新篇章。
这个 RFC 10008 是 2026 年 6 月 16 日正式发布的。它定义了全新的 HTTP 请求方法 QUERY，填补了 GET 和 POST 之间长期存在的空白。让它既能像 POST 一样携带请求体传输复杂查询，又能像 GET 一样保持安全、幂等和可缓存的语义。
接下来，我们就一起来围绕这个 http QUERY 方法，解读它的设计背景、核心特性、实际应用场景以及落地前景。
文章配图参见 https://mp.weixin.qq.com/s/uA1z0qUiBCz_Zt6iZN_-7g。
复杂查询该用 GET 还是 POST？
写过 Java 的都知道，在 RESTful API 设计中，查询数据本该是 GET 的“主场”。这种做法在简单场景下，一切都很美好。
GET /api/v1/users?role=admin&status=active&sort=desc HTTP/1.1但当查询条件变得复杂，比如多层嵌套过滤、复杂的关系查询、长文本搜索、或者包含数十个参数的报表查询，这种情况下各种问题就接踵而至了。
- URL 长度限制：浏览器和代理服务器通常对 URL 长度有 2KB~8KB 的限制，复杂查询很容易“爆表”
- 编码噩梦：特殊字符、非 ASCII 内容需要 URL 编码，不仅增加体积，还严重降低可读性
- 数据结构表达困难：数组怎么传？
?roles[0]=admin还是?roles=admin&roles=reporter？不同框架处理方式各异 - 安全隐患：查询参数会被记录在服务器日志、浏览器历史、甚至第三方分析工具中，敏感信息容易泄露
- 资源标识混乱：每一种查询参数组合都被视为一个“独立资源”，违背了 REST 的资源定位原则
那用 POST 带请求体？这确实也是业界多年来的“潜规则” workaround。但 POST 的语义是“非幂等的资源创建/处理”，用它来执行只读查询，等于向整个 HTTP 基础设施“撒谎”。
- CDN 和代理不会缓存 POST 响应
- 自动重试机制不敢对 POST 请求“动手”，因为担心重复提交导致副作用
- 监控和日志系统无法区分”创建订单”和”搜索订单”
在这方面，GraphQL 就是一个典型例子，所有操作（包括纯查询）都走 POST，导致 HTTP 层级的缓存和重试优势完全丧失，社区不得不发明 persisted queries、CDN 专用规则等 workaround 来弥补。
QUERY 方法
2026 年 6 月 16 日，IETF 正式发布了 RFC 10008（The HTTP QUERY Method），为这个困扰多年的问题给出了标准答案。
QUERY 方法就是同时有 GET 的语义 + POST 的载体。
核心定义
QUERY 方法本质上是一个可以携带请求体的 GET。RFC 10008 明确其语义，如下所示。
A QUERY requests that the request target process the enclosed content in a safe and idempotent manner and then respond with the result of that processing.
下面，用一张表来对比三种方法的差异。
| 特性 | GET | POST | QUERY |
|---|---|---|---|
| 安全（无副作用） | 是 | 否 | 是 |
| 幂等（可安全重试） | 是 | 否 | 是 |
| 可缓存 | 是 | 实际不可 | 是 |
| 携带请求体 | 否 | 是 | 是 |
| 语义清晰度 | 高 | 模糊 | 高 |
一个典型的 QUERY 请求
QUERY /contacts HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json
{
"filter": {
"department": "engineering",
"skills": ["Go", "Rust"],
"hire_date": { "gte": "2023-01-01" }
},
"sort": [{ "field": "level", "order": "desc" }],
"page": { "size": 20, "token": "abc123" }
}服务器返回如下所示。
HTTP/1.1 200 OK
Content-Type: application/json
Accept-Query: "application/json", "application/sql"
[ { "name": "Alice", "level": "P8" }, ... ]QUERY 方法解决了什么核心问题？
其实上面已经解释的差不多了，下面我们来看看官方给出的更纯正的说法。
语义正确性
QUERY 让 API 设计回归“诚实”，只读查询就是只读查询，不再需要用 POST “伪装”。这对基础设施的每一层都意义重大。
- 代理/CDN：看到 QUERY 就知道可以缓存、可以重试
- 客户端 SDK：可以安全地实现自动重试和断路器
- 监控系统：能准确区分”读操作”和”写操作”的流量模式
- API 文档：开发者一看方法就知道这个端点是查询而非创建
复杂查询的表达自由
JSON、SQL、JSONPath、GraphQL 查询语句……只要服务器支持，都可以放在请求体中。RFC 10008 引入了新的响应头 Accept-Query，服务器用它来声明支持的查询格式。
Accept-Query: "application/json", "application/sql;charset=UTF-8", "application/jsonpath"缓存机制
QUERY 响应是可缓存的，但缓存键需要同时考虑 URL 和请求体内容。RFC 10008 允许对请求体进行“语义规范化”（如忽略空白差异）来提升缓存命中率。服务器还可以通过 Location 响应头为查询结果分配一个持久 URI，后续客户端可以直接用 GET 访问这个 URI，避免重复发送查询体。
自动重试的安全性
因为 QUERY 是幂等的，客户端在遭遇网络超时、连接中断时，可以放心地自动重试，无需担心重复执行导致数据不一致。这是 POST 查询永远无法提供的保障。
何时落地？
看起来 Http 的这个 Query 方法好处挺多的，哪它什么时候能真正落地呢，接下来我们看看官方给出的进展。
支持进展
RFC 10008 目前处于提议标准（Proposed Standard）阶段，这意味着。
- 标准已获 IETF 批准，技术方案稳定
- 广泛落地仍需时间，取决于浏览器、服务器、框架、代理、工具链的逐步适配
目前已知支持或正在适配的程序或工具部分列举如下。
- curl：已支持（使用
-X QUERY或--request QUERY），Daniel Stenberg（curl 作者）已发文确认 - Kreya：API 调试工具 Kreya 在 1.20 版本中已原生支持 QUERY 方法
- 部分 Web 框架：如 .NET 10 可通过
app.MapMethods(pattern, ["QUERY"], handler)手动暴露端点
尚未完全支持的部分列举如下。
- 主流浏览器：目前 HTML 表单仍只支持 GET/POST，浏览器默认不会发送 QUERY 请求
- OpenAPI/Postman：这些 API 文档和测试工具尚未原生建模 QUERY 方法
- Nginx/Apache/CDN：大多数反向代理和 CDN 默认只放行”标准”HTTP 方法，需要配置调整
什么时候该用？
如果未来 2 年内都得到支持了，包括 Java 基础类库，Spring 生态里的一些框架等，那么下面这些场景就可以使用上 Http 的 Query 方法了。
| 场景 | 推荐方法 |
|---|---|
| 简单查询，参数少，需要分享/收藏链接 | GET |
| 复杂查询，嵌套过滤，大量参数，JSON 结构 | QUERY |
| 创建/更新/删除资源 | POST / PUT / PATCH / DELETE |
| 需要立即分享查询结果的链接 | GET（QUERY 的请求体无法编码到 URL 中） |
最后
RFC 10008 的发布，不是对 GET 或 POST 的否定，而是对 HTTP 方法语义完整性的补全。它解决了一个几乎所有 API 开发者都遇到过、却长期没有标准答案的问题。
当然，从“提议标准”到“全面落地”，QUERY 还需要数年时间。浏览器支持、框架原生集成、基础设施适配、开发者习惯培养，每一步都需要时间。但正如 HTTP/2、HTTP/3 的普及历程一样，一旦生态成熟，QUERY 将成为复杂查询场景的默认选择。
QUERY 对带来一大批新需求，尤其是各种基础设施，包括浏览器、各种语言类库、开源框架、应用程序等。在不久的将来，内部系统、微服务间通信、API 调试工具等可控环境中，QUERY 肯定会流行起来。毕竟，语义正确的 API 设计，是构建可维护系统的基石。
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！