摘要： IETF 在 2026 年 6 月中把 HTTP QUERY 發表為 RFC 10008。QUERY 的安全與冪等語意和 GET 相同，但可攜帶請求主體，讓複雜唯讀查詢避開網址長度限制，也避免 POST 重試可能帶來的副作用。文章提醒目前生態支援仍有限，上線前要測試請求路徑上的每一站。
HTTP QUERY 在 2026 年 6 月中由 IETF 正式發表為 RFC 10008。沒隔幾天，Kreya 這款開發者工具的作者寫出長文，拆解它要解決的問題，文章 6 月 23 日攻上 Hacker News 首頁，收到數百則留言。會有這種聲量，是因為它踩中的痛，每個設計過 API 的人都熟悉。
一句話就能說清 QUERY 的角色：安全與冪等和 GET 相同，差別只在能帶請求主體。
草稿磨多年，終於成為 RFC
RFC 10008 出自 Julian Reschke、James M. Snell（Cloudflare）與 Mike Bishop（Akamai）之手，源頭是 HTTPBIS 工作小組的草稿 draft-ietf-httpbis-safe-method-wbody。熬了這麼多年——2022 年起就不斷有人在 Hacker News 轉貼討論，2025 年 11 月第 14 版又掀起一波熱度，如今才塵埃落定成為 Proposed Standard——正說明「安全方法可不可以帶主體」在工程圈始終談不攏，最後得靠一份 RFC 收尾。
GET 撐不住、POST 又語意錯置
源頭在這裡：複雜的讀取查詢硬塞進 GET 網址，會撞上長度上限，特殊字元得編碼，敏感參數還會隨網址進到伺服器日誌，陣列與巢狀結構更是各家 API 自行發明約定。改用 POST 送得出去，語意卻整個不對——它沒有冪等性，自動重試可能造成副作用，中介軟體也無法視之為唯讀、可快取。「GET 帶主體」規範未明文禁止卻明確不建議，實作各行其是：有的打回票，有的悄悄丟掉主體，有的照樣處理。
QUERY 的做法是另訂新方法，不重新定義 GET。查詢長什麼樣，由請求內容與其媒體類型說了算，規範點名 form-urlencoded、SQL、JSONPath、XSLT 幾種可能形式，並涵蓋內容協商、錯誤碼（400、415、422、406）、以 Content-Location 與 Location 回報結果位址、重導向、條件請求與範圍請求。
快取行為與新的 Accept-Query 標頭
有兩處設計值得細看。一是快取：QUERY 回應可以快取，但 RFC 把話說死，實作「必須把請求內容納入快取鍵」，否則不同查詢會共用同一份快取——自行實作時最容易在這裡出錯，也比 GET 的快取更麻煩。二是全新的 Accept-Query 回應標頭，一種 Structured Field，讓伺服器主動列出接受的查詢媒體類型，客戶端不必再猜。
生態現況則該看保守些：作者不諱言採用還很有限，部分客戶端、代理伺服器與網頁伺服器可能直接擋下 QUERY 請求，離全面普及還有好幾年。Kreya 已在 1.20 版內建原生支援。
給 API 設計者的採用建議
那篇解說的建議很實際：簡單查詢留在 GET，不必特意改；需要可分享、可加書籤的連結時，GET 仍是正確答案；只有複雜唯讀查詢才值得換成 QUERY，上線前則要把請求路徑上每一站都測過。
對 agent 與 API 工具開發者，這另有一層意義：結構化查詢改放請求主體後，編碼規則與網址長度再也管不著它，程式或模型產出的查詢無須再擠進查詢字串。HTTP 方法家族多年未增成員，QUERY 是少見真正新添的基礎能力；代理、框架與用戶端要多久才會全面接受仍難料，但走向已經底定。