http status code的使用問題
- WBOY原創
- 2016-09-19 09:16:301221瀏覽
作為一個前端,最近開始寫後台,遇到了一些restful設計上的問題,希望各位大神解答一下。
restful規範特別的強調了HTTP Status Codes的使用，但是我在使用的時候卻有一些疑惑。尤其是在回傳錯誤訊息這塊。
我自己使用時是約定好一套關於業務的錯誤碼，比如20001,代表'缺少xxx字段',把他放在http response body裡面返回，然後在response頭裡面寫好200 OK之類的。
例如login的時候,假如前端傳過來的json裡面沒有password字段,
那我返回一個400 Bad Request的http報文,同時報文的body部分如下(僅僅舉個例子哈,一切從簡):
<code>{
"code":20001,
"message":"缺少password字段"
}</code>
對於上面這樣的處理方式,主要的疑問點在於:
有的時候的業務上的錯誤不知道該用哪個HTTP Status Codes,比如說新建用戶,如果說用戶名已存在,那我這個時候body部分很好搞,但是HTTP Status Codes應該用哪個呢?400 Bad Request肯定不對吧,人家前端傳過來的信息沒有問題,401 Unauthorized 403 Forbidden之類的感覺也不能用在這,所以這時候的HTTP Status Codes狀態碼到底應該用什麼呢?
確實有很多同學在使用時是不管什麼情況都返回200 OK,然後在http body部分用json去返回錯誤信息,但我還是覺得HTTP Status Codes是restful中很重要的一部分,restful規範也很強調對其的使用,所以我還是希望大家給我指條明路,這部分到底該怎麼弄。
回覆內容：
作為一個前端,最近開始寫後台,遇到了一些restful設計上的問題,希望各位大神解答一下。
restful規範特別的強調了HTTP Status Codes的使用，但是我在使用的時候卻有一些疑惑。尤其是在回傳錯誤訊息這塊。
我自己使用時是約定好一套關於業務的錯誤碼，比如20001,代表'缺少xxx字段',把他放在http response body裡面返回，然後在response頭裡面寫好200 OK之類的。
例如login的時候,假如前端傳過來的json裡面沒有password字段,
那我返回一個400 Bad Request的http報文,同時報文的body部分如下(僅僅舉個例子哈,一切從簡):
<code>{
"code":20001,
"message":"缺少password字段"
}</code>
對於上面這樣的處理方式,主要的疑問點在於:
有的時候的業務上的錯誤不知道該用哪個HTTP Status Codes,比如說新建用戶,如果說用戶名已存在,那我這個時候body部分很好搞,但是HTTP Status Codes應該用哪個呢?400 Bad Request肯定不對吧,人家前端傳過來的信息沒有問題,401 Unauthorized 403 Forbidden之類的感覺也不能用在這,所以這時候的HTTP Status Codes狀態碼到底應該用什麼呢?
確實有很多同學在使用時是不管什麼情況都返回200 OK,然後在http body部分用json去返回錯誤信息,但我還是覺得HTTP Status Codes是restful中很重要的一部分,restful規範也很強調對其的使用,所以我還是希望大家給我指條明路,這部分到底該怎麼弄。
建議看一下http status code列表，4xx的回應碼還是很多的，一般4xx也是代表是請求錯誤。
規範只是大體建議，按照規範來可以，你搞個233 ok也行，關鍵是協調好，留下相關文檔...
假設是在網站型的程式中使用，網站說白了是給用戶看的，誠然網頁不存在要返回404，但是這個功能web服務器一般會幫我們做，不過單純的在出錯的時候使用一個服務器給出的預設頁面是不夠的，網站是給人看的，用戶才不管你回碼設定的有多科學，你就是把回傳碼玩出花來，他們也不買你的帳。所以說，對於網站來說，可以給出常用的返回碼，但是重點在於展示的頁面。至於是不是回傳碼是400 401之類的，你做再講究不如一個出錯訊息提示頁來的簡潔明快。
對於API型的應用來說，假設這個API是給前端ajax用的，如果你在業務邏輯出錯的時候給了一個HTTP協議的狀態碼，那麼它只會在控制台上打印一條錯誤日誌。如果你用的是jquery來處理的ajax，那麼它就會觸發error函數回調，這肯定不是你想要的，正常的做法是返回json數據，這個json中帶有返回碼和錯誤信息，在出錯的時候將json中的錯誤訊息欄位顯示出來。如果你在出錯時用返回碼，則在error回調中還拿不到具體的錯誤原因，你只能顯示一個模糊的信息，操作xxx出錯了，這肯定不是用戶想要的，這同時增加了客服的難度，用戶再跟客服描述的時候只能描述一個模糊的問題。當然還有一個隱藏的問題，假設你使用了反向代理，前端程式也沒辦法區分目前的非法的回傳碼到底是web應用程式回傳的，還是反向代理伺服器回傳的。
假設你在純伺服器之間的API之間使用自訂HTTP返回碼，你會發現開發者僅僅解析一個HTTP返回碼是不夠的，他們想知道錯誤的詳細信息，這時候你還得回傳一個json數據。當然上面說的反向代理的問題，在這裡依然存在。
所以綜上所述，我是不推薦使用自訂HTTP返回碼的，雖然它很科學，但是它太學究，不實用。特別對於網站應用程式遇到連結找不到或未捕獲異常，才返回404或500，而且返回的時候要使用友好的出錯頁來承載，其他邏輯錯誤也盡量使用錯誤頁來承載。
422 Unprocesable entity - [POST/PUT/PATCH] 當建立一個物件時，發生一個驗證錯誤。
感覺這個合適唉
422 Unprocesable entity - [POST/PUT/PATCH] 當建立一個物件時，發生一個驗證錯誤。
這個提示也不錯
有衝突訊息的話也可以使用 409 Conflict
這邊HTTP狀態碼解析可以看下
http://jingyan.baidu.com/arti...