1. 題目與適用場景
設計一個 REST API：用戶端可以查詢列表、更新資料與刪除資源。面試官要求你解釋為什麼某些成功請求回傳 200，另一些回傳 204，以及空列表、找不到資源和成功刪除應如何表達。假設用戶端依賴穩定的 JSON 契約，閘道也會記錄回應本體大小。
2. 面試官考察點
- 是否理解 204 的核心限制是成功且沒有訊息本體，而不是「結果為空」。
- 是否能把資源表示、集合語意與用戶端解析行為放在同一份契約討論。
- 是否知道 RFC 9110 對 204 的快取與中繼資料規則，能說明 ETag 等回應標頭仍有價值。
- 是否能給出 200、204、404 的可預期選擇，而非死記某個方法的固定狀態碼。
3. 回答前需要釐清的問題
- 請求是否成功改變資源，還是讀取一個集合的表示？
- 用戶端是否需要新的 JSON 表示、分頁中繼資料或下一步連結？
- 「沒有結果」代表合法的空集合，還是目標資源不存在？
- DELETE 的冪等語意與重複刪除的產品契約是什麼？
4. 30 秒回答框架
先判斷成功回應是否需要攜帶表示：需要 JSON、分頁資訊或資源狀態時用 200；操作成功且用戶端不需要訊息本體時用 204。列表查詢得到合法空集合仍回傳 200 和 []，因為集合表示存在；單一目標不存在才考慮 404。DELETE 常用 204，但若要回傳刪除後的稽核資訊或統一信封，就用 200。最後說明 204 不可傳送訊息本體，並測試用戶端對兩種成功回應的處理。
5. 分步驟深入解答
第一步：區分「空表示」與「無表示」
200 表示請求成功並允許回傳表示。GET /users?team=none 找到一個合法集合，只是成員數為零，因此回傳 200、[] 和分頁欄位，用戶端仍可按列表契約解碼。204 表示操作已成功，但回應不包含訊息本體；它適合不需要新表示的更新或刪除確認。
第二步：為寫入操作選擇狀態碼
PATCH 成功後若用戶端需要伺服器正規化後的物件、版本號或欄位，就回傳 200 和資源表示；若用戶端只需知道寫入完成，回傳 204，並可用 ETag 或其他標頭傳遞版本中繼資料。DELETE 成功通常回傳 204；如果 API 要回傳撤銷令牌、稽核紀錄或統一回應信封，則回傳 200。兩種做法都要在所有端點保持一致。
第三步：處理 404 與重複請求
空列表不是 404，因為集合資源存在。請求具體 /users/42 而資源不存在，才使用 404。對 DELETE 的重複呼叫，要先定義「已不存在」是否視為成功：若 DELETE 設計為冪等且不洩露資源存在性，可再次回傳 204；若業務需要通知用戶端物件從未存在，也可以回傳 404，但必須記錄在契約中。
第四步：驗證協定和用戶端行為
204 回應不能包含訊息本體，用戶端不得無條件呼叫 JSON 解析。契約測試應涵蓋狀態碼、Content-Length、回應標頭和空本體；瀏覽器、SDK、代理與快取層都要驗證。若資源版本透過 ETag 傳遞，用戶端可在後續 If-Match 請求中使用它，而不必把物件表示塞進 204。
6. 高品質示範回答
我會先問用戶端是否需要新的資源表示。需要物件、分頁欄位或統一 JSON 信封時回傳 200；操作完成但沒有內容要交給用戶端時回傳 204，並確保回應沒有訊息本體。合法的空列表仍是 200 加 []，因為集合存在；具體資源不存在才是 404。PATCH 在需要伺服器正規化結果時回傳 200，否則回傳 204 並帶 ETag。最後用契約測試確認用戶端不會對 204 做 JSON 解析，並明確定義重複 DELETE 的產品語意。
7. 常見錯誤
- 把「列表為空」回傳 204 → 用戶端失去統一的陣列和分頁契約 → 回傳 200 與空集合表示。
- 在 204 回應中放 JSON 信封 → 違反無訊息本體限制且不同代理處理不一致 → 移除回應本體或改用 200。
- 認為 DELETE 永遠必須是 204 → 忽略稽核資訊或正規化結果需求 → 根據是否需要表示選擇 200 或 204。
- 把所有空結果當成 404 → 混淆集合存在與成員不存在 → 先判斷請求目標是集合還是具體資源。
- 用戶端對所有 2xx 都呼叫 JSON 解析 → 204 會觸發解析例外 → 依狀態碼分支處理並增加契約測試。
8. 追問及應對
追問一：GET 查詢沒有符合項目，可以回傳 204 嗎？
技術上可以表示無內容，但會破壞列表端點的統一形狀。只要查詢本身成功且集合存在，優先 200 加空陣列與分頁中繼資料；只有契約明確把「無表示」當作結果時才用 204。
追問二：204 可以帶 ETag 嗎？
可以。204 沒有訊息本體，但回應標頭仍可攜帶資源版本等中繼資料。用戶端可以保存 ETag，在下一次條件更新中傳送 If-Match，從而避免為傳遞版本而回傳完整物件。
追問三：重複 DELETE 應該回傳 204 還是 404？
取決於冪等與資訊揭露策略。若「刪除後目標狀態就是不存在」且不需要區分首次與重複呼叫，可以穩定回傳 204；若呼叫方必須知道資源是否曾存在，則回傳 404。選擇應固定在 API 契約，不要依實作路徑隨機變化。