通用面試：HTTP 510 Not Extended 代表什麼，現代 API 該不該使用？

題干與適用場景

遺留客戶端會送出 HTTP 擴充宣告，部分請求要求伺服器必須理解該擴充；現有閘道可能轉送請求，但來源站不支援擴充。請解釋 510 Not Extended 的語意，比較 501 與 400，並提出相容、觀測、遷移與回滾方案。

RFC 2774 將這套擴充框架標為 Historic。本題考察協定語意判斷，不代表 510 在當代公共 API 中普遍部署。

面試官考察點

• 是否知道 510 只對應未滿足的 HTTP 擴充要求，而非一般業務驗證失敗。
• 能否區分來源站不理解擴充（510）與不支援請求方法（501）。
• 能否識別 RFC 2774 的歷史狀態，避免把罕見狀態碼當通用錯誤格式。
• 能否把代理、快取、相容性與遷移證據放進同一方案。

回答前需要釐清的問題

1. 請求是否真的宣告 RFC 2774 的強制擴充，還是只是帶有未知業務標頭？
2. 哪一跳（客戶端、代理、閘道或來源站）能識別擴充宣告？
3. 客戶端是否能升級，是否有穩定的替代請求格式？
4. 510 回應是否會被中介層改寫、快取或統一包裝？
5. 遷移期間是否需要同時相容唯讀與寫入操作？

30 秒回答框架

「510 是 RFC 2774 為強制 HTTP 擴充請求定義的回應：伺服器無法滿足請求宣告的擴充。501 表示伺服器不支援請求方法，400 表示請求語法或語意無效。由於 RFC 2774 已是 Historic，我會先確認流量確實使用該框架，再把 510 當成遺留相容訊號，回傳可診斷但不洩露內部資訊的錯誤體，記錄擴充識別與鏈路，並推動客戶端遷移到明確版本化的 API 契約。若只是未知業務標頭或一般驗證失敗，不應回傳 510。」

分步驟深入解答

1. 先驗證擴充宣告

RFC 2774 的情境不只是「伺服器看到陌生標頭」。客戶端宣告擴充及其識別，並可要求接收方必須理解它。先在原始請求、代理轉送紀錄與來源站紀錄中確認宣告是否存在，再判斷 510 是否成立。

2. 區分相鄰狀態碼

510 表示請求要求的擴充無法滿足；501 表示伺服器不支援完成請求所需的方法；400 表示請求本身無法按一般語意解析或處理。認證、權限、限流或業務規則應使用對應狀態碼與穩定業務錯誤碼，不要借用 510。

3. 設計可診斷回應

回應應包含穩定錯誤類型、請求 ID、擴充識別的安全摘要與遷移文件連結。避免回顯未驗證的 URI、內部元件名稱或敏感請求內容。若統一錯誤體使用 application/problem+json，510 只表達協定層原因，業務細節放在擴充欄位。

HTTP/1.1 510 Not Extended
Content-Type: application/problem+json
Cache-Control: no-store

{"type":"https://api.example/problems/unsupported-extension","title":"Required extension is unsupported","status":510,"instance":"req-7f2"}

4. 處理代理與快取

驗證代理是否會移除擴充宣告、把 510 改寫成 400，或在快取層重用錯誤回應。對包含身分、能力協商或租戶資訊的回應使用謹慎快取策略；紀錄請求路徑、擴充識別、代理版本與來源站結果，避免把完整敏感請求寫入紀錄。

5. 規劃遺留遷移

先按客戶端版本與擴充識別統計失敗率，提供不依賴該擴充的版本化請求格式，並在文件與 SDK 中給出切換期限。遷移窗口內可同時接受舊格式與新格式，但必須明確能力協商與回滾條件。達到覆蓋率門檻後再停止舊擴充，避免直接把 510 變成永久客戶故障。

6. 設定驗證與回滾

用真實代理鏈與契約測試驗證四種路徑：擴充被支援、擴充缺失、擴充被中介層剝離、一般未知標頭。監控 510、501、400 的比例及客戶端升級率；若 510 激增且與設定發布相關，先恢復相容路徑，再修正擴充解析，而不是簡單重試來源站。

高品質示範回答

「我先從封包與代理紀錄確認是否存在 RFC 2774 的強制擴充宣告。只有來源站無法滿足該擴充時才使用 510；方法不支援是 501，普通語法或業務請求無效是 400。RFC 2774 已是 Historic，因此我會把 510 限定為遺留相容訊號，回傳穩定錯誤類型、請求 ID 與遷移文件，採用謹慎快取並記錄擴充識別、代理和客戶端版本。接著提供版本化的無擴充 API，透過契約測試驗證代理轉送和錯誤改寫，按升級率逐步關閉舊路徑，並保留可回滾開關。」

常見錯誤

• 看到未知標頭就回傳 510 → 未證明存在強制擴充 → 先解析擴充宣告與能力要求。
• 把 510 當成 501 → 混淆擴充無法滿足與方法未實作 → 按 RFC 情境和請求方法分別判斷。
• 把 510 設計成長期公共 API 約定 → 生態相容成本高 → 標註 Historic，優先版本化遷移。
• 錯誤回應可被共享快取 → 一個客戶端的能力結果影響其他客戶端 → 按身分與協商資訊設定快取策略。
• 只重試舊請求 → 不支援的擴充不會因重試而出現 → 轉向升級、降級或替代格式。

追問及應對

510 和 501 的一句話差別是什麼？

510 針對請求宣告的 HTTP 擴充無法滿足；501 針對伺服器不支援請求方法或完成該方法所需的實作。兩者都不應替代一般業務錯誤碼。

未知業務標頭應回傳 510 嗎？

不應直接這樣做。未知標頭可能被忽略、由業務契約拒絕，或需要回傳 400；只有請求明確要求 RFC 2774 風格的強制擴充且伺服器無法滿足時，510 才有語意依據。

為什麼 RFC 2774 的 Historic 狀態會影響設計？

它提示實作與客戶端生態有限、互通性風險較高。面試回答應把 510 當成遺留協定相容點，並用觀測、契約測試與版本化遷移控制風險，而非假設所有現代 HTTP 堆疊都支援該框架。