HTTP 新增 QUERY 方法：有人叫好，也有人质疑“这不就是 GET？”
文章来源声明：
来源站点：InfoQ 中文； 原文链接：https://www.infoq.cn/article/BmJh0DzGPYBEl1zlyO0C?utm_source=rss&utm_medium=article； 本文基于上述来源整理/加工，觅优补充点评，仅供技术学习交流。版权归原作者所有。
- 2026-09-15北京
- 本文字数：1371 字
阅读完需：约 4 分钟
HTTP 在 RFC 10008 中正式标准化 QUERY 方法，填补了安全、幂等且支持请求体的读取操作语义空白。该方法允许结构化查询通过正文传递，规避 GET 的 URL 长度与隐私缺陷，同时避免 POST 的非安全副作用。
QUERY 支持缓存、重试与中间件优化，语义明确区别于现有方法。
标准由 IETF 正式发布，核心作者含 Reschke、Snell、Bishop，源于 2019 年 HTTP Workshop 讨论。
适合 Web 协议设计者、API 架构师、后端工程师阅读
2026 年 6 月，HTTP 迎来了 16 年来最重要的新增功能：IETF 发布了 RFC 10008，为 Web 引入了一种名为 QUERY 的新方法。这是自 PATCH 于 2010 年落地以来，第一个新的标准 HTTP 动词。它由 Julian Reschke、James Snell 和 Mike Bishop 编写，起源于 Asbjørn Ulsberg 在 2019 年 HTTP Workshop 上重新发起的一场讨论。
QUERY 旨在解决开发者多年来一直争论的问题。GET 是安全且幂等的，但其过滤条件必须放在 URL 中，不仅会受到长度限制、泄露到访问日志中，也难以表达嵌套结构。POST 可以携带内容丰富的正文，但它既不安全也不幂等，因此缓存会跳过它，客户端无法安全地重试它，中间系统也必须假定它会改变状态。QUERY 补上了缺失的第三种选择：像 POST 一样携带正文，同时保留读取操作所具有的安全、幂等和可缓存语义。
在实践中，过去必须压缩到 URL 中的搜索：
GET /orders?select=email&limit=10&match="email=*@example.*"
现在可以改为在正文中发送过滤条件，不必担心大小问题：
QUERY /orders HTTP/1.1
Host: api.example.org
Content-Type: application/json
{ "select": ["email"], "limit": 10, "match": "email=@example." }
只要缓存键包含请求内容，响应就仍然可以缓存，服务器还可以通过新的 Accept-Query 字段声明支持该方法。
一个 [r/webdev 讨论帖](https://www.reddit.com/r/webdev/comments/1u82ghz/new_query_method_is_about_to_join_get_post_put/)获得了超过 800 个赞，其中一位开发者问道：
> 为什么不允许 [GET 请求携带可选正文](https://www.reddit.com/search/?q=HTTP+request+body+in+GET&cId=0ce327d0-619c-44c8-9359-5a8b8ed6997e&iId=1d1859c2-d726-4f49-b0c9-453dbf8f283e)？
另一位开发者解释了原因：
> 通过引入一种新方法，你可以确保对方支持请求正文。
>
> 调试请求无法正常工作的原因会容易得多。因为不支持该方法的服务器会提示“QUERY 不受支持”。
>
> 对 GET 正文进行静默失败处理是最显而易见的做法。祝你好运，希望你能调试出链路中的哪台服务器丢弃了你的正文……
在 [Hacker News](https://news.ycombinator.com/item?id=48640974) 上，围绕使用 GET 和可选正文也出现了类似的讨论，一位评论者总结道：
> “QUERY 就是 GET”
>
> “使用带正文的 GET 是可行的”
>
> 大家似乎都没有理解这一点。你本来就不应该使用带正文的 GET，这是一种变通手段，因此提供一种明确的方法是合理的。
>
> 能用并不意味着用法正确。
同一讨论还指出，如今就连 Cloudflare 也会伪造一个 GET 缓存键来缓存 POST：
> ……他们对 POST 请求缓存的非官方支持方式，是创建一个虚假的 GET 请求作为缓存键，并用它来缓存响应。正因为没有 QUERY 这样的方法，所有人才不得不采用这类变通手段。
[GraphQL](https://graphql.org/) 和 [Elasticsearch](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html) 已经通过 POST 正文传输复杂的读取请求，而 QUERY 提供了一种基于标准的替代方案，同时让这些读取请求保持可缓存性。工具生态也在逐步跟进：Rust 的 [http crate](https://github.com/hyperium/http/pull/798) 已经合并相关支持，[.NET](https://github.com/dotnet/aspnetcore/issues/61089)、[Axum](https://github.com/tokio-rs/axum/issues/3799)、[Quarkus](https://github.com/quarkusio/quarkus/issues/55494) 和 [Bruno](https://github.com/usebruno/bruno/issues/8589) 也在跟踪相关工作。
该[规范](https://datatracker.ietf.org/doc/rfc10008/)建议将 QUERY 视为一项补充，而不是全面替代现有方法。[IETF 草案历史](https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/)记录了它从早期带正文的安全方法工作发展到如今标准正式发布的漫长历程。这也提醒人们，与此前的 PATCH 一样，QUERY 的实际普及很可能需要以年为单位衡量。
HTTP 是 Web 运行所依赖的请求和响应协议，其规范由 IETF 的 HTTP 工作组（即 httpbis）制定，再由 RFC Editor 以 RFC 的形式发布。新方法十分罕见，因为每种方法都必须得到客户端、服务器、代理和缓存的理解，才能在实践中可靠使用。正因如此，RFC 10008 将 QUERY 定位为 GET 和 POST 之外的可选补充，而不是对二者中任何一个的替代。
原文链接：<https://www.infoq.com/news/2026/09/http-query-method/>
</div></div>
对 API 架构师和后端工程师而言，QUERY 为复杂读取请求提供标准化的可缓存方案，值得在搜索、GraphQL 类接口试点，但普及仍需数年。