QUERY 是一个提案中的 HTTP 方法，填补了一个真实的空白：它像 GET 一样
安全（safe）、幂等（idempotent），又像 POST 一样可以携带
请求体（body）。可以把它理解为 “可以带 body 的 GET”。
它为什么存在
复杂查询长期面临一个尴尬的二选一：
GET+ 查询串：所有过滤条件塞进 URL。URL 有长度限制、会以明文记入日志， 对结构化或嵌套的条件也很笨拙。POST+ 请求体：能装下 payload，却谎报了意图。POST既不安全也不幂等， 于是缓存、爬虫与中间件只能假设该请求会改变状态。但它并不会 —— 你只是在读。
QUERY 化解了矛盾：语义表明*“这是一次读取”*，而请求体承载查询条件。
特性
| 特性 | QUERY | GET | POST |
|---|---|---|---|
| 安全 | ✓ | ✓ | ✗ |
| 幂等 | ✓ | ✓ | ✗ |
| 请求体 | ✓ | ✗ | ✓ |
| 可缓存 | ✓ | ✓ | 有条件 |
一个请求长什么样
QUERY /products HTTP/1.1
Host: shop.example
Content-Type: application/json
Accept: application/json
{ "category": "boots", "inStock": true }用 Content-Location 缓存
因为 QUERY 安全且幂等，响应可以被缓存 —— 但缓存键不能只用 URL，因为 body 会变。
服务端用 Content-Location 头指明结果的规范位置：
HTTP/1.1 200 OK
Content-Location: /products?category=boots&inStock=true
Cache-Control: max-age=60缓存（或客户端）随后即可对等价请求复用该表示。这正是让「带 body 的读取」保持 可缓存的机制。
动手试试
到 实时测试 向本站回显端点发起一个真实的 QUERY 请求，
直观看到 method、headers 与 body 如何抵达服务端。
QUERY 定义在一份 IETF Internet-Draft 中，仍在演进。以上细节请当作工作摘要， 以链接的 draft 原文为权威与最新依据。