http status code的使用問題

作為一個前端,最近開始寫後台,遇到了一些restful設計上的問題,希望各位大神解答一下。
restful規範特別的強調了 HTTP Status Codes的使用，但是我在使用的時候卻有一些疑惑。尤其是在 返回錯誤資訊這塊。
我自己使用時是約定好一套關於業務的錯誤碼，比如20001,代表'缺少xxx欄位',把他放在http response body裡面返回，然後在response頭裡面寫好200 OK之類的。
比如login的時候,假如前端傳過來的json裡面沒有password欄位,
那我返回一個 400 Bad Request的http報文,同時報文的body部分如下(僅僅舉個例子哈,一切從簡):

{"code":20001,"message":"缺少password欄位"}

對於上面這樣的處理方式,主要的疑問點在於:
有的時候的業務上的錯誤不知道該用哪個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":20001,"message":"缺少password欄位"}

對於上面這樣的處理方式,主要的疑問點在於:
有的時候的業務上的錯誤不知道該用哪個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出錯了，這肯定不是使用者想要的，這同時增加了客服的難度，使用者再跟客服描述的時候只能描述一個模糊的問題。當然還有一個隱藏的問題，假設你使用了反向 Proxy，前端程式也沒法區分當前的非法的返回碼到底是web應用程式返回的，還是反向 Proxy伺服器返回的。

假設你在純伺服器之間的API之間使用自訂HTTP返回碼，你會發現開發人員僅僅解析一個HTTP返回碼是不夠的，他們想知道錯誤的詳細資料，這時候你還得返回一個json資料。當然上面說的反向 Proxy的問題，在這裡依然存在。

所以綜上所述，我是不推薦使用自訂HTTP返回碼的，雖然它很科學，但是它太學究，不實用。特別對於網站應用程式程式遇到連結找不到或者未捕獲異常，才返回404或者500，而且返回的時候要使用友好的出錯頁來承載，其他邏輯錯誤也盡量使用錯誤頁來承載。

422 Unprocesable entity - [POST/PUT/PATCH] 當建立一個對象時，發生一個驗證錯誤。

感覺這個合適唉

422 Unprocesable entity - [POST/PUT/PATCH] 當建立一個對象時，發生一個驗證錯誤。

這個提示也不錯

有衝突資訊的話也可以使用 409 Conflict

這邊HTTP狀態代碼解析可以看下
http://jingyan.baidu.com/arti...

