HTTP 迎来 16 年来首个全新请求方法：`QUERY`

如果你开发过 REST API，一定对 GET、POST、PUT、DELETE 等 HTTP 方法非常熟悉。

但你知道吗？2026 年 6 月 ，IETF 正式发布了 RFC 10008 ，为 HTTP 标准新增了一种全新的请求方法------QUERY。

这是继 2010 年 PATCH（RFC 5789） 之后，HTTP 标准首次新增请求方法。也就是说，HTTP 请求方法已经 16 年没有迎来新的标准成员。

RFC 10008（The HTTP QUERY Method）

www.rfc-editor.org/info/rfc100...

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

需要说明的是，RFC 10008 定义的是一种新的 HTTP 请求方法，而不是新的 REST 规范。 它的目标是在保持 HTTP「安全（Safe）」和「幂等（Idempotent）」语义的前提下，为需要复杂请求体的查询操作提供标准支持。

---

为什么 GET 不够用了？

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

例如，一个查询订单的接口：

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

一开始，这种方式完全没有问题。

但随着业务越来越复杂，问题也逐渐显现。

例如：

• URL 长度存在限制（很多服务器限制在约 8 KB 左右）
• 查询参数容易出现在浏览器历史、日志或代理记录中，不适合携带敏感信息
• 很难表达复杂查询，例如 SQL、JSONPath、DSL 或多层过滤条件
• URL 参数编码繁琐，可读性和维护性都比较差

于是，越来越多的开发者开始寻找替代方案。

---

为什么大家都改用 POST？

现实中，大量查询接口实际上都是这样实现的：

POST /orders
Content-Type: application/json

{
  "select": ["surname", "givenname", "email"],
  "limit": 10,
  "match": "email=*@example.*"
}

因为请求体（Body）几乎没有长度限制，也更适合组织复杂数据。

但这样又带来了新的问题。

虽然这个 POST 请求实际上只是查询数据，并不会修改服务器状态，但 HTTP 协议本身无法知道这一点。

因此：

• 无法利用 GET 的标准缓存机制
• 浏览器、CDN 和代理服务器无法确定请求是否可以缓存
• 网络异常时，客户端通常不敢自动重试
• 各个框架只能各自实现所谓的「安全 POST」，缺乏统一标准

---

QUERY 就是为了解决这个问题

新的 HTTP QUERY 方法允许开发者：

• 使用请求体（Request Body）发送复杂查询
• 同时明确告诉 HTTP：这是一次只读查询，不会修改服务器状态。

例如：

QUERY /orders
Content-Type: application/json

{
  "select": ["surname", "givenname", "email"],
  "limit": 10,
  "match": "email=*@example.*"
}

这样既保留了 POST 的灵活性，又拥有了 GET 的语义。

---

QUERY 有哪些优势？

1. 不受 URL 长度限制

所有复杂查询都可以放进请求体，例如：

• SQL
• GraphQL 查询
• JSONPath
• Elasticsearch DSL
• 多条件过滤

都无需再拼接到 URL 中。

---

2. 属于安全（Safe）请求

RFC 10008 明确规定：

QUERY 是一种 Safe Method。

也就是说，它只能读取资源，不允许修改服务器状态。

这一点与 GET 完全一致。

---

3. 支持幂等（Idempotent）

这里也是很多文章容易解释错误的地方。

幂等（Idempotent）并不等于可以缓存（Cacheable）。

HTTP 对幂等性的定义是：

多次执行同一个请求，对服务器最终状态产生的影响，与执行一次完全一致。

例如：

PUT /users/1

重复执行十次，服务器中的数据最终仍保持一致，因此 PUT 是幂等的。

再例如：

DELETE /users/1

第一次删除成功，后续再次删除不会进一步改变服务器状态，因此 DELETE 同样是幂等的。

而：

POST /users

每发送一次都会创建一个新用户，因此 POST 不是幂等的。

同样，QUERY 也是幂等的。

因为无论发送多少次，它都只是执行查询，不会改变服务器状态。

---

幂等 ≠ 可缓存

这是 HTTP 中最容易混淆的两个概念。

**幂等性（Idempotency）**描述的是：

重复执行请求，对服务器状态的影响是否一致。

**可缓存性（Cacheability）**描述的是：

响应是否允许浏览器、代理服务器或 CDN 缓存，以便后续直接复用。

二者并没有必然联系。

例如：

HTTP 方法	幂等	默认可缓存
GET	✅	✅
QUERY	✅	✅（RFC 10008 定义支持缓存）
PUT	✅	❌
DELETE	✅	❌
POST	❌	一般不缓存

因此，不要把「幂等」理解成「可以缓存」。

只是 GET 和 QUERY 同时具备了这两种特性，因此容易让人误以为两者存在因果关系。

---

为什么 QUERY 支持缓存？

因为 QUERY 明确告诉 HTTP：

这是一次不会修改数据的查询请求。

因此：

• 浏览器可以缓存
• CDN 可以缓存
• HTTP 代理可以缓存

这意味着复杂查询终于可以享受标准 HTTP 缓存机制，而无需继续依赖各种「POST 查询」的变通方案。

---

一个有趣的新能力：查询本身也可以拥有 URI

传统 POST 更关注返回查询结果：

POST /orders

Content-Location: /results/123

而 QUERY 可以返回代表查询本身的 URI：

QUERY /orders

Location: /saved-queries/42

之后再次访问：

GET /saved-queries/42

服务器会重新执行当初保存的查询，并返回最新的数据。

这意味着你可以：

• 收藏一个查询
• 分享查询链接给同事
• 定时重新执行查询
• 缓存查询，而不仅仅是缓存结果

---

API 设计也会变得更简单

过去，我们可能会设计多个接口：

GET /users/active
GET /users/inactive
GET /users/premium

有了 QUERY 后，可以统一为：

QUERY /users

不同的查询条件全部放入请求体中。

这样不仅接口数量更少，也更容易维护、扩展和监控。

---

总结

QUERY 并不是为了取代 GET 或 POST。

它更像是在两者之间补上了一块长期缺失的拼图：

• 像 GET 一样，只负责查询，不修改数据（Safe）。
• 像 GET 一样，具备幂等性（Idempotent），可以安全重试。
• 像 GET 一样，支持 HTTP 标准缓存机制。
• 像 POST 一样，支持请求体，不受 URL 长度限制，适合复杂查询。

需要特别强调的是，幂等性（Idempotency）与可缓存性（Cacheability）是两个独立的概念 。PUT 和 DELETE 虽然也是幂等方法，但默认并不可缓存；而 QUERY 同时具备幂等和可缓存特性，这是由 RFC 明确定义的。

目前，QUERY 已于 2026 年 6 月 正式成为 RFC 10008 标准。不过，由于服务器、客户端以及各种 Web 框架仍在逐步跟进，实现支持还需要一定时间，预计将在 2027～2028 年逐渐普及。

在正式用于生产环境之前，建议先关注各大 HTTP Server、API Gateway、浏览器及框架对 QUERY 的支持情况。但对于 API 设计者而言，现在了解它的设计理念和适用场景，将有助于构建更加规范、易扩展的 REST API。

---

参考资料

• RFC 10008 -- The HTTP QUERY Method（官方）
  www.rfc-editor.org/info/rfc100...
• RFC 10008 HTML 版本
  www.rfc-editor.org/rfc/rfc1000...