本文同步發布於個人部落格

為什麼不把 api 的 status code 跟昨天的 api 文章合在一起呢？
因為可以水一篇文章啊
好啦，其實我也想過要合在一起，但有些東西想特別挑出來說說，單獨開一個短篇章好像好一點？
MDN 其實已經把 status code 定義得清清楚楚，我這篇文章其實也沒想一步步去寫每個 status code 的定義。
我想說的是，實務上，status code 其實如果團隊有協議，其實是可以客製的！
HTTP 協議的 status code 就像 restful 規範一樣，都是一個參考的準則，實務上可以依照團隊的需求來調整。

當然團隊在規範仍然會盡量按照 HTTP 協議為 status code 區分的五大類來區分：

1. 100 系列：request 已經被接收，並且正在處理中。
2. 200 系列：request 已經成功處理。
3. 300 系列：request 已經被接受，但需要重導向相關操作。
4. 400 系列：用戶端錯誤。
5. 500 系列：server 端出現了錯誤。

然後一些常看到的 status code，諸如 401、404 也不會特別去改掉，而是依照約定俗成的用法。
實務開發上其實很少會用到 100 系列與 300 系列的 status code，但 200、400 以及 500 確幾乎貫穿了整個開發過程。

200 ok

200 是 status code 中最和平的狀態碼，代表一切都很順利。
前端開發中當然最喜歡這個 status code，因為這表示 api request 順順利利、前後端溝通無礙。

在 200 系列中，其實也還有像 201 這種明確定義是給用於資源創建成功的狀態碼。
但一般為了方便，有時也會把乾脆把一切成功的 api request 都統一回傳 200。
這沒什麼問題，因為對於前端來說，串接 api，無論 restful 還是 GQL 都一定是會有一份 api document 可以看的。
可以從文件中明確知道成功的 api request 會回傳什麼樣的資料、還是不會回傳任何資料，那統一 200 其實不會有什麼問題。

萬惡的 400 系列

400 系列是開發中最常見的 status code，因為這代表客戶端有錯誤。
一般有幾個 status code 最常見：

1. 400 Bad Request
2. 401 Unauthorized
3. 404 Not Found

400 是最常見的錯誤，代表客戶端發送的請求有誤，可能是參數錯誤、格式不正確等。
反正就是後端驗證資料失敗往往就會吐這個回來。
開發時遇到這個錯誤，通常前端就要查一下自己的 code 了，往往都是 POST 前的 form data 沒有 format 成後端需求的格式，或是 URL 的 query string 沒有正確傳遞。
所以開發參閱 api document 是很重要的！

401 算是一個無傷大雅的錯誤，因為這代表客戶端沒有提供有效的身份驗證憑證，也就是沒登入啦。
登入一下就好了。

404 大部分人會想到網頁不存在，但網頁不存在那是屬於前端設定路由的範疇。
api 的 404 往往指的是這筆資料在後端的資料庫中不存在。
404 尤其好發在前端 delete 資料時。當前端送出 delete 的 request 時，往往在 server response 後會再 get 一次資料庫的資料，來更新前端的畫面。
但有時因為後端 server 一些延遲的操作，這一次的 get 可能還是會包含剛剛那筆被刪除的資料，如果又再去點擊刪除，後端就會回傳 404，因為實際上那筆資料其實剛剛已經被刪除了，只是中間的那個 get 不知為何還是回傳了那筆資料 (可能是因為 DB or 快取同步延遲)。
遇到這種問題，請直接炸後端。

另外如果有在接第三方服務，有時也會看見 403 Forbidden，這個錯誤代表客戶端沒有權限訪問請求的資源。
通常是因為工程師的 token 權限不足，這個情況一般可以直接找公司或團隊 MIS 或 DevOps 人員來協助處理。

額外要講的是 422。
一般團隊客製化錯誤時，會優先選 422 來客製。
比如某個特別重要的驗證沒過，或是某個付款沒過，就會回傳 422，前端也往往也會為 422 特製一個專門的 error handler。
比如一般 400 都是提示「請檢查輸入的資料是否正確」的 notify，但 422 可能就會直接跳個更加醒目的 dialog 來提示使用者。

遇到基本可以直接找後端的 500 error

另一個開發也稍微常遇到的是 500 error。
遇到這個通常只需要做兩件事：

1. 先看專案 master 是否最近更新了什麼 code，需要更新一下 package、submodule 還是 env 變數。
2. 如果第一點確定都沒錯，那基本可以直接找後端了~

通常實務開發上，在 dev 環境外還會有個 stage 環境模擬生產環境做測試用，一般來說如果是 stage 遇到 500 error，可以找找 DevOps，因為可能是部署時有些環境變數沒有設定好或是 server 臨時掛了。
而 prod 如果突然遇到 500 error，嗯，那沒意外的話應該是發生意外了，請為那個公司的 server 先默哀一下，它可能在短時間遭遇了大量的請求，這時先不要慌，後面的 DevOps 跟後端應該比我們更慌。

錯誤處理

前一篇有講到會需要針對 api error 來製作 error handler。
一般來說，error handler 會根據不同的 status code 來進行分類處理，主要會分給開發人員看的，還是給使用者看的。

有些錯誤，當很確定是只需要給開發者知道的話，通常就會把 error handler 限制在 dev 環境中。
比較善於管理的團隊會導入如 Sentry 這類的錯誤追蹤工具，來收集和分析錯誤資訊。

而像 400 這類跟表格驗證較相關的錯誤，通常後端驗證失敗都會伴隨 error response 回傳。
一般前端可以選擇摘取 error message 出來顯示給使用者，或是進一步將 error response 做拆解，在表格的對應欄位顯示錯誤訊息。