IETF 发布了 RFC 10008，正式定义了 HTTP 的 QUERY 方法。这是一个介于 GET 和 POST 之间的新请求方法，允许客户端在请求体中发送复杂的查询条件，同时明确保证操作是安全且幂等的——这意味着它可以被缓存、自动重试，而不会引发副作用。
为什么需要 QUERY 方法
过去的 HTTP 查询有两种做法：通过 GET 将参数塞进 URL，或通过 POST 把查询内容放在请求体里。GET 的局限性很明显——URL 长度有限，不适合传递大量或结构化的查询条件。POST 虽然能携带任意大小的请求体，但语义上并不区分“查询”和“创建／修改”；外部观察者（如缓存代理、浏览器）无法仅凭 POST 就断定这是一个只读操作，因此很难放心地对它做缓存或自动重发。
RFC 10008 填补了这个空白。QUERY 方法像 GET 一样被标记为安全（不对服务器资源产生状态变更）和幂等（重复执行结果相同），同时又像 POST 一样允许将查询内容作为请求的 body 发送。服务器收到 QUERY 请求后，根据请求内容中的媒体类型和元数据，在目标资源的范围内执行查询，并以 200 OK 返回结果。
规范还引入了“等价资源”（Equivalent Resource）的概念：服务器可以为某个 QUERY 请求派生出一个对应的 GET 资源 URI，客户端后续可以用 GET 直接获取相同的查询结果。这使得重要查询可以被赋予一个唯一的 URI，符合 RESTful 设计“每个重要资源都应有一个 URI”的原则。
对开发者和协议生态的影响
对于 API 设计者，QUERY 方法提供了一条清晰的路径：当你需要让客户端提交一个复杂查询（例如 SQL-like 筛选、大段 JSON 条件），又不希望该操作被误解为数据变更时，应该使用 QUERY 而不是 POST。缓存中间件、CDN 和 HTTP 客户端库也可以根据 QUERY 的安全幂等特性，放心地缓存响应或在连接失败后自动重试，而无需担心副作用。
不过，QUERY 方法并非强制替代现有做法；服务端可以选择是否实现。对于简单的键值查找，URL 参数形式的 GET 仍然高效；对于需要创建资源的操作，POST 依然是正确选择。QUERY 的出现，更多是让 HTTP 方法家族在语义上更加完备，让“只读查询”这个高频场景有了一个标准化的专属动词。
编注：信源为 IETF RFC 10008（互联网标准跟踪文档），材料聚焦方法定义与语义，未涉及具体实现或向后兼容性分析。