如果你开发过 REST API，一定对 GETPOSTPUTDELETE 等 HTTP 方法非常熟悉。

但你知道吗？2022 年 10 月IETF 发布了 RFC 9449为 HTTP 标准新增了一种全新的请求方法——QUERY。

这是继 2015 年 PATCH 之后HTTP 标准首次新增请求方法。说白了近 7 年没有迎来新的标准成员.

QUERY 的出现，主要是为了解决一个开发者多年来一直在绕过的问题：如何优雅地发送复杂查询请求。

注意：QUERY 是一种新的 HTTP 请求方法，而不是新的 REST 规范。它在保持 HTTP「安全」和「幂等」语义的前提下为需要复杂请求体的查询操作提供标准支持。

为什么 GET 不够用了？

按照 REST 的设计原则，查询资源通常应该使用 GET。

示例：

GET /orders?select=surname,givenname。email&limit=50&match="email=*@example.*"

A) 起初，这种方式完全没有问题。但因为业务越来越复杂，以下痛点逐渐浮现：

• ID1： URL 长度限制导致请求被截断。
• ID2： 查询参数会出现在浏览器历史、日志或代理记录中，不适合携带敏感信息。
• ID3： 难以表达复杂查询。
• ID4： URL 参数编码繁琐，可读性和维护性差。

A) 为了解决这些痛点，开发者开始寻找替代方案。

为什么大家都改用 POST?

A) 在实际项目中，大量查询接口都是这样实现的：

POST /orders
Content-Type: application/json
{
"select":。"limit": 50,"match": "email=*@example.*"
}

• A1) 请求体几乎没有长度限制，非常适合组织复杂数据。
• A2) 只是这会产生新的问题：
  • P1： P1: 无法利用 GET 的标准缓存机制。
  • P2： 浏览器、CDN 与代理服务器无法判断该请求是否可以缓存。话说回来，
  • P3： 网络异常时客户端往往不敢自动重试。因为 HTTP 协议无法确认它是「安全」的。按理说，
  • P4： 各框架只能自行实现「安全 POST」。缺乏统一标准，

QUERY: 为上述痛点提供统一答案

A) 新增的 HTTP 方法允许开发者：

• A1) 使用请求体发送任意复杂查询；
• A2) 明确告知 HTTP：This is a read‑only query that never modifies server state.

Simplified example:

QUERY /orders
Content-Type: application/json
{
"select":。"limit": 50,"match": "email=*@example.*"
}

A) 此方式保留了

优势？

. 不受 URL 长度限制

A) 所有复杂查询均可放入请求体，例如：

• - SQL 脚本；
• - GraphQL 查询；
• - JSONPath 表达式；
• - Elasticsearch DSL；
• - 多条件过滤组合；

B) 再也不用担心 URL 超限或手动拼接参数导致错误。

. 属于安全请求