2026 年 6 月中，IETF 把 HTTP QUERY 方法正式發布為 RFC 10008。幾天後，開發者工具 Kreya 的作者撰寫長文解說這個新方法究竟解決什麼問題，6 月 23 日登上 Hacker News 首頁，湧入數百則討論。一個 HTTP 方法能引起這種關注，原因很簡單：它踩到了每個 API 設計者都遇過的痛。
QUERY 的定位一句話講完：像 GET 一樣安全、冪等，但可以帶請求主體。
從草稿到 RFC 的一步
RFC 10008 由 Julian Reschke、James M. Snell（Cloudflare）與 Mike Bishop（Akamai）合著，前身是 HTTPBIS 工作小組的草稿 draft-ietf-httpbis-safe-method-wbody。這份草稿的歷史不短——Hacker News 上從 2022 年起就有人反覆張貼討論，2025 年 11 月第 14 版時又熱過一輪，如今總算以 Proposed Standard 之姿定案。標準化走了這麼多年，恰恰說明「安全方法能不能帶主體」在工程界始終沒有共識，最後需要一份 RFC 來一錘定音。
GET 的極限與 POST 的語意債
問題的根源：把複雜的讀取查詢塞進 GET 網址，會撞上網址長度限制；特殊字元要編碼；敏感參數會跟著網址一起進到伺服器日誌；陣列與巢狀結構的約定則是各家 API 各自發明。改用 POST 在技術上可行，語意卻全錯——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 是少數真正新增的基礎能力——代理、框架與各種用戶端需要多久才能全面接受它，仍是未知數，但方向已經定下來了。
參考來源
- RFC 10008: The HTTP QUERY Method — RFC Editor
- The new HTTP QUERY method explained — Kreya
- RFC 10008 — IETF Datatracker
本文由 AI 協助自上述來源整理，經人工審核後發布。