題幹與適用情境
RFC 10008 在 2026 年 6 月定義 HTTP QUERY 方法。它允許客戶端把描述查詢的內容放在請求內容中，同時宣告對目標資源是 safe、idempotent 的操作。題目考察協定語意與基礎設施現實之間的差距，不要求立即遷移所有既有 POST 搜尋介面。
面試官考察點
面試官會看你是否理解 QUERY 不是「帶 body 的 GET 別名」，而是一種獨立方法：請求內容與媒體類型參與查詢語意，回應快取鍵必須考慮請求內容，跨域通常需要預檢。強回答還會討論 OPTIONS 或 Accept-Query 能力探索、未知方法的 405 回退、閘道日誌與 WAF 相容性。
回答前需要釐清的問題
查詢是否真的只讀
確認查詢不會改變目標資源狀態。safe 與 idempotent 約束的是目標資源語意，伺服器仍可能建立承載結果的額外資源，不能把「無副作用」理解成絕對沒有寫入。
生態支援範圍
列出瀏覽器 Fetch、SDK、反向代理、CDN、WAF、服務網格與內部客戶端是否接受 QUERY。新方法即使在應用伺服器可用，也可能在中間層被拒絕或改寫。
快取與隱私要求
查詢內容可能包含敏感篩選條件。確認哪些層會記錄請求 URI、請求內容和快取鍵，並決定是否允許共享快取、需要脫敏或改用 POST。
30 秒回答架構
「QUERY 適合把複雜查詢放入請求內容，同時保留安全、冪等和可快取的協定意圖。我會先用 OPTIONS 的 Allow 或回應的 Accept-Query 探索能力，再在真實代理、CDN、WAF 和客戶端矩陣中做相容性驗證。快取鍵必須包含請求內容與相關媒體類型，跨域請求要處理預檢。若生態尚未支援，我會保留 GET 的短查詢和 POST 的相容路徑，不把 RFC 語意直接當成基礎設施已完成升級。」
分步深入解答
第一步：判斷 GET、QUERY、POST 的邊界
短小、可加入書籤、可複製的查詢仍適合 GET；查詢內容複雜但目標資源只讀時可評估 QUERY；若操作會改變狀態、生態不支援新方法或需要既有表單相容，則繼續使用 POST。方法選擇應由語意與部署矩陣共同決定。
第二步：定義內容類型與服務契約
QUERY 必須帶有與請求內容一致的 Content-Type。契約應說明查詢格式、分頁、排序、錯誤回應，以及結果是否可透過 Content-Location 或 Location 另行 GET 取得。
第三步：做能力探索與安全回退
用 OPTIONS 的 Allow 或 Accept-Query 表明資源支援的方法和查詢媒體類型。客戶端遇到 405、415 或閘道拒絕時，按明確策略回退到 POST，不能盲目重試而放大流量。
第四步：設計快取與重試
QUERY 是冪等的，可以在連線失敗後重試，但快取鍵必須納入請求內容和相關中繼資料。規範化請求內容時要確保快取層與來源站語意一致，避免把一個查詢結果錯誤提供給另一個查詢。
第五步：驗證跨域與營運鏈路
QUERY 不屬於 CORS safelisted methods，瀏覽器跨域會觸發預檢。驗證 OPTIONS、Allow、日誌、指標、WAF 規則、限流和追蹤鏈路都能識別新方法，並記錄回退比例與錯誤原因。
高品質示範回答
我不會因為 RFC 10008 發布就批量替換 POST。對小型、可分享的過濾請求繼續使用 GET；對只讀但查詢內容很大、需要明確方法語意的介面，才在受控客戶端中試用 QUERY。伺服器要求正確的 Content-Type，用 Accept-Query 或 OPTIONS 宣布支援；快取鍵包含請求內容和媒體類型，跨域客戶端完成預檢。發布前我會讓瀏覽器、SDK、閘道、CDN、WAF 和服務網格通過一組真實查詢，觀察 405、415、快取錯配與日誌截斷。若任何關鍵層不支援，就保留 POST 回退並監控使用比例，直到遷移證據充分。
常見錯誤
- 錯誤表現： 把 QUERY 當成可以帶 body 的 GET。→ 失敗原因： 方法語意、快取和能力探索規則不同。→ 修正方法： 按 RFC 定義請求內容、safe、冪等與快取鍵。
- 錯誤表現： 只在應用伺服器上測試。→ 失敗原因： 代理、WAF、CDN 或 SDK 可能拒絕未知方法。→ 修正方法： 做全鏈路相容性矩陣並準備 POST 回退。
- 錯誤表現： 快取只按 URI 建鍵。→ 失敗原因： 不同請求內容可能得到錯誤共享結果。→ 修正方法： 將請求內容和相關中繼資料納入鍵，並驗證規範化規則。
- 錯誤表現： 認為冪等代表可以無限重試。→ 失敗原因： 重試仍會消耗資源並放大查詢負載。→ 修正方法： 配合逾時、退避、限流與查詢複雜度上限。
追問及應對
追問一：為什麼不把所有複雜查詢都改成 QUERY？
方法語意只是條件；客戶端、代理、CDN、WAF 和監控需要共同支援。遷移成本和回退複雜度超過收益時，繼續使用成熟的 POST 更穩妥。
追問二：QUERY 的回應能快取嗎？
可以，但快取鍵必須包含請求內容與相關中繼資料，且快取層要理解媒體類型。若結果含敏感資料或規範化風險高，應限制共享快取或透過等價資源的 GET 存取。
追問三：瀏覽器跨域呼叫會發生什麼？
QUERY 不在 CORS safelisted methods 中，會觸發預檢。伺服器必須正確回應 OPTIONS，並允許實際方法、請求標頭和來源；預檢失敗時應顯示明確的客戶端錯誤。
追問四：未知閘道回傳 405 怎麼辦？
讀取 Allow 判斷支援方法，按版本化客戶端策略回退到 POST。記錄回退原因和比例，避免把未知方法錯誤當成業務查詢失敗。