欢迎访问本站，持续更新中…
RSS

WikiFw 维基框架

RFC 10008：HTTP 终于有了 QUERY 方法

1 天前 HTTPRFC编程

封面

等了几十年，HTTP 协议终于加了一个新动词。

RFC 10008。HTTP Query Method。

我看到这个消息的时候，第一反应是——终于有人把这件事给正式化了。

什么意思呢？

你用 REST API 做过复杂查询吧？比如"获取过去 30 天内、消费金额大于 1000、且地址在北京市朝阳区的用户列表"。

以前的做法是什么？GET 请求，把条件拼在 URL 参数里。

GET /users?created_after=2026-05-17&min_amount=1000&city=北京&district=朝阳

参数少的时候还行。一旦查询条件复杂起来——嵌套、OR 逻辑、模糊匹配、分页、排序——URL 就变成一个怪物了。而且 URL 有长度限制（很多服务器默认 8KB），查询条件一复杂就超了。

然后大家开始用各种变通方案： - POST 请求带 JSON body（虽然语义上是 GET，但 POST 能传大 body） - GraphQL（专门发明一套查询语言） - OData（微软那套，复杂到没人想用）

说实话，POST 做查询这件事，我一直觉得别扭。它违反了 REST 的幂等性原则——POST 本意是"创建资源"，拿来查询语义上就不对。

RFC 10008 定义了一个新 HTTP 方法：QUERY。

内容

QUERY 方法的核心设计是这样的：

  • 请求有 body（和 POST 一样），可以放复杂的查询条件（JSON 格式）
  • 语义是幂等的（和 GET 一样），不会修改服务器状态
  • 响应是缓存友好的（和 GET 一样）
  • 没有 URL 长度限制的问题

举个例子：

QUERY /users HTTP/1.1
Content-Type: application/json

{
  "filter": {
    "and": [
      {"field": "created_at", "op": "gte", "value": "2026-05-17"},
      {"field": "total_spent", "op": "gte", "value": 1000},
      {"field": "address.city", "op": "eq", "value": "北京"}
    ]
  },
  "sort": [{"field": "created_at", "order": "desc"}],
  "page": {"offset": 0, "limit": 20}
}

干净。语义清晰。而且查询条件可以无限复杂，不受 URL 长度限制。

但——问题来了。

生态支持。

现在你用 QUERY 方法发请求，大部分 HTTP 客户端库（OkHttp、Apache HttpClient、curl）都不直接支持。你得手写 HTTP 协议。

Spring Boot 呢？@QueryMapping 这种注解还没有。你得自己写一个 HandlerMapping 来处理 QUERY 方法。

浏览器呢？fetch API 的 method 参数虽然可以传自定义字符串，但浏览器可能不会正确处理 QUERY 的缓存语义。

CDN 和反向代理呢？Nginx、CloudFlare、Varnish——它们的缓存策略都是基于 GET/HEAD 的，QUERY 默认不会被缓存。

所以说白了，RFC 10008 是个好设计，但要真正用起来，整个 HTTP 生态链——客户端库、Web 框架、浏览器、CDN、代理——都需要适配。

这个过程，保守估计得三到五年。

不过对于新项目来说，现在就可以开始关注了。如果你在做 API 设计，可以提前把 QUERY 方法纳入规范，等生态成熟了直接用。

总比到时候再改强。

反正我是觉得——这个 RFC 虽然来得晚，但总比不来好。

金句

关于维基框架

维基框架（Wiki Framework）是一套面向复杂业务场景的轻量级开发框架，支持多语言、多协议、多部署形态。适用于企业级应用开发、微服务架构、云原生部署等场景。