題幹與適用場景
API 回傳很大的 JSON，客戶端保存了上一個 ETag。請說明何時可以使用 HTTP 226 IM Used、客戶端與伺服器需要交換哪些標頭，以及增量無法套用時如何保證正確性。回答應涵蓋協定協商、快取和降級，不要求實作特定差分演算法。
面試官考察點
- 是否理解 226 是 GET 差分結果的狀態碼，不是「成功但內容不完整」。
- 是否能把
A-IM、IM、ETag與可選的Delta-Base串成完整往返。 - 是否識別基準版本、快取並發、演算法成本和回退完整 200 的邊界。
- 是否能指出部署前要驗證客戶端、中間快取和實作支援度。
回答前需要澄清的問題
- 客戶端能否執行約定的 instance manipulation 演算法？
- 文件是否有穩定 ETag，增量生成的 CPU 與頻寬收益是否值得？
- 請求是否經過會改寫或快取回應的代理？
- 舊基準失效、差分過大或校驗失敗時，是否能重新取得完整表示？
30 秒回答框架
我會先把 226 當成能力協商後的最佳化路徑。客戶端帶上 A-IM 和基準表示的 If-None-Match；伺服器只有在支援演算法且能找到基準時，才回傳 226、IM、新 ETag，必要時帶 Delta-Base。客戶端驗證基準 ETag 後合併差分並校驗新實體標籤。任何不匹配、成本不划算或客戶端不支援都回傳完整 200，並記錄命中率、差分大小和失敗原因。快取只在基準與回應元資料都符合時接受結果。
分步驟深入解答
1. 先協商差分能力
A-IM 列出客戶端接受的 instance manipulation；伺服器選定演算法後在回應 IM 宣告。它和內容編碼壓縮不同：壓縮改變傳輸編碼，差分改變表示的產生方式。沒有可接受演算法時應走普通 200。
2. 固定基準並綁定版本
客戶端用 If-None-Match 指定本地實體標籤。伺服器必須確認該標籤對應基準表示，不能只靠時間或客戶端自報版本猜測。回應帶新 ETag；Delta-Base 可明確指出差分所依據的標籤。客戶端合併後要確認結果與新標籤一致。
3. 設計安全回退
基準不存在、差分大於完整文件、演算法逾時、合併校驗失敗或代理不可靠時，回傳完整 200。客戶端也應把基準標成不可用並重新同步，避免錯誤差分繼續套用。伺服器可設大小、CPU 與時間門檻。
4. 處理快取與可觀測性
快取鍵必須涵蓋 URL、協商標頭和決定基準的條件；不能把只對某個 ETag 有效的差分當成通用回應。監控 226 命中率、差分與完整回應位元組、合併失敗、回退比例和生成耗時，持續驗證收益。
高品質示範回答
我會把它當成有明確回退的協定最佳化。客戶端先宣告支援的 A-IM 演算法，並用 If-None-Match 指向本地基準。伺服器檢查基準是否仍可用、演算法是否在允許清單，再比較差分大小和生成成本；符合條件才回傳 226，並用 IM 告知演算法、新 ETag 標識結果，必要時用 Delta-Base 標識基準。客戶端驗證基準標籤、合併差分、校驗新實體標籤後才替換文件。任何版本不匹配、差分過大、校驗失敗或鏈路不支援都回退 200。快取按協商能力與基準條件隔離，監控節省位元組、CPU、失敗和回退。這樣保留增量傳輸收益，又不把差分機制當成可靠性前提。
常見錯誤
- 把 226 當成 206，忽略 206 是 Range 請求的部分內容。
- 只傳一個「版本號」，沒有用 ETag 綁定確切基準。
- 假設所有瀏覽器、代理和快取都會自動理解差分。
- 不比較差分與完整文件大小，造成 CPU 增加而流量沒有下降。
- 合併失敗後繼續沿用舊基準，而不是重新取得完整表示。
- 把壓縮、JSON Patch 和 RFC 3229 的 instance manipulation 混為同一層協定。
追問及應對
226 與 206、304 有什麼差別？
206 回應 Range 請求的位元組區間；304 表示條件請求下無需傳送新表示；226 表示伺服器回傳基於既有表示的差分結果。三者的請求條件、客戶端處理和快取語義不同。
基準 ETag 過期時怎麼辦？
不能盲目套用差分。伺服器應回傳完整 200，或先讓客戶端取得目前基準；客戶端清除不可用基準並從完整表示重新建立快取。
如何防止差分快取污染？
嚴格綁定 URL、協商演算法、基準 ETag 和回應 ETag，校驗 IM 與 Delta-Base，避免代理重用只對特定基準有效的回應，並對合併後實體做完整性檢查。