長期以來，網頁開發者在處理複雜的資料查詢時，始終在 GET 與 POST 兩種 HTTP 方法之間面臨兩難。HTTP 是定義網頁客戶端與伺服器之間溝通的基礎協定，由 IETF（網際網路工程任務組）的 httpbis 工作組負責制定標準並發布為 RFC 文件。在傳統的 RESTful 設計中，GET 方法被定義為安全（Safe）且冪等（Idempotent），意即發送請求不會改變伺服器狀態，且多次重複發送相同請求會得到相同結果，因此非常適合快取。然而，GET 的參數必須放在 URL 的查詢字串中，這導致了三個主要痛點：首先，URL 有長度限制，無法承載極其複雜的篩選條件；其次，敏感資訊會直接暴露在瀏覽器歷史記錄或伺服器存取日誌中；最後，URL 難以表達深層的嵌套結構。
為了繞過這些限制，許多開發者選擇使用 POST 方法，因為 POST 允許在請求主體（Request Body）中攜帶大量且結構化的資料。但問題在於，根據標準，POST 被視為會改變伺服器狀態的操作，因此絕大多數的快取伺服器會直接跳過 POST 請求，且客戶端在網路不穩時無法安全地自動重試。這導致像 GraphQL 或 Elasticsearch 這種需要複雜查詢的技術，不得不將讀取操作封裝在 POST 中，進而失去了 HTTP 原生快取的優勢，甚至迫使像 Cloudflare 這樣的服務商必須採取非標準的技巧，例如偽造一個 GET 快取鍵來強行快取 POST 回應。
背景與核心內容
為了徹底解決這個矛盾，IETF 於 2026 年 6 月正式發布了 RFC 10008 標準，引入了一個全新的 HTTP 方法：QUERY。這是自 2010 年 PATCH 方法推出以來，HTTP 協定中第一個新增的標準動詞。QUERY 方法的核心設計目標是創造一種第三選擇：它像 POST 一樣允許攜帶請求主體，但同時繼承了 GET 的安全與冪等特性。
簡單來說，QUERY 方法讓開發者可以在請求主體中使用 JSON 等結構化格式來定義複雜的篩選條件，而不需要將所有參數強行擠進 URL 中。例如，原本需要寫成冗長 URL 的搜尋請求，現在可以改用 QUERY 方法，將篩選條件放在 Body 中，而伺服器端只要將請求內容納入快取鍵（Cache Key）的計算，依然可以對其進行高效快取。此外，伺服器可以透過全新的 Accept-Query 欄位來告知客戶端自己支援此方法。
技術脈絡與實務意義
在技術討論中，常有人質疑為什麼不直接允許 GET 方法攜帶請求主體。事實上，雖然部分伺服器在實作上允許這樣做，但這被視為一種危險的駭客行為（Hack）。如果將 Body 放在 GET 中，當請求經過多層代理伺服器或閘道器時，某些中間設備可能會在不通知客戶端的情況下悄悄丟棄 Body，導致除錯極其困難。
而引入獨立的 QUERY 方法則提供了明確的語義。如果伺服器不支援此方法，它會直接回傳「QUERY not supported」的錯誤訊息，讓開發者能立即發現問題，而非在沉默中失敗。這種明確的定義確保了整個網路鏈路中的所有參與者（包括瀏覽器、代理伺服器與快取層）都能對該請求的性質達成共識：這是一個攜帶複雜參數的讀取操作，且它是安全的。
影響與限制
儘管 QUERY 方法解決了長期的痛點，但其普及過程將會面臨挑戰。由於 HTTP 是全球基礎設施，任何新方法的推行都需要客戶端、伺服器、代理伺服器以及快取系統全面同步支援才能發揮最大效用。這也是為什麼 RFC 10008 將 QUERY 定位為一個可選的增強功能，而非對 GET 或 POST 的強制替代方案。
目前，開發工具鏈已開始逐步跟進。例如 Rust 語言的 http crate 已合併相關支援，.NET、Axum、Quarkus 以及 API 測試工具 Bruno 等也正在追蹤實作。然而，參考過去 PATCH 方法的經驗，一個新標準從發布到被工業界大規模採納通常需要數年時間。在過渡期間，開發者應將其視為一種優化選項，在確保基礎設施支援的前提下，將複雜的讀取請求從 POST 遷移至 QUERY，以重新獲得標準化的快取能力與更好的語義清晰度。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。