此篇用於記錄在開發前後端分離的Twitter專案時，邊摸邊學的筆記，當時是第一次設定回傳的status code，雖然沒經驗，但想藉此把這件事做好，很感激自己立下的小小目標。雖然說是4字頭系列，但還是會含有少量非4開頭的status code。
＊本篇使用情境不代表該status能用的全部，而是指我在開發時的使用情境。
Status Code與他們的使用情境
成功回傳200
201 Created
原本想要在使用者成功新增推文、帳號時回傳201 Created，但是測試檔預期接收到200，便作罷。
4xx
400 Bad Request response
使用情境A：圖片上傳失敗
會使用400是因為這個錯誤是客戶端造成的，導致我們無法處理這個請求，但感覺有更好的status code可以處理這個，目前我是根據stackoverflow上網友的建議來寫的。
為何會說有更好的寫法？因為根據RFC，400通常用在requset時的語法錯誤，文件中也提到deceptive request routing，這個也跟錯誤的格式有關係，像是header有些欄位格式不正確or遺失、被狹持的cookie…
綜觀下來400感覺是跟HTTP格式錯誤比較有關，而非檔案上傳失敗。
這一篇則是建議使用409，有興趣也能看看。
情境B：使用者request時資料帶的不完整或是有誤
像是必填欄位沒填。這是根據stackoverflow這則討論串的建議來設定。
401 Unauthorized
情境A：使用者未登入
參照RFC，可以看出是跟使用者驗證有關：
The "Authorization" header field allows a user agent to authenticate
itself with an origin server -- usually, but not necessarily, after
receiving a 401 (Unauthorized) response. Its value consists of
credentials containing the authentication information of the user
agent for the realm of the resource being requested.
情境B: 密碼錯誤
根據RFC，401也可用在當他要登入時，credentials有誤（像是密碼or信箱都可以，看你是定義要驗證什麼）:
Upon receipt of a request for a protected resource that omits
credentials, contains invalid credentials (e.g., a bad password) or
partial credentials (e.g., when the authentication scheme requires
more than one round trip), an origin server SHOULD send a 401
(Unauthorized) response that contains a WWW-Authenticate header field with at least one (possibly new) challenge applicable to the
requested resource.
情境C：資源存在，但是無權限操作，像是編輯非本人的推文。
403 Forbidden
使用情境：權限不足，像是user不能使用admin限定的功能
回傳409 Conflict
使用情境：帳號/Email 已被使用
RFC:
indicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request.
雖然RFC也指出，409通常用在PUT，但是依照這個情境，還是這個敘述最適合他了，stackoverall也有一篇針對這個狀況的熱烈討論。
5xx
500 Internal Server Error
使用情境：我們自己伺服器出問題，像是code寫錯（server端自己跳錯）
詳細的錯誤訊息會用message: err，放入錯誤詳情。
我發現雖然有RFC這個文件可以參照，但是大家對同一條都有不同的解讀，導致同一種情境可能大家的設定方式都不同，也因為這是我第一次設status code，考量到開發時程，想趕快給前端串API，所以當下並無過於琢磨，事後想想，或許能夠觀察其他網站的處理方式，但這個感覺比較複雜，有時間才能來實驗。
