假設，客戶端發送了一個請求到伺服器，伺服器驗證資料後，發覺不符合，需要回傳一個錯誤。
我理解是，客戶端由於請求過程是正確的，所以即使資料格式不符合服務端的要求，服務端也應該返回200狀態碼，然後在正文裡帶回錯誤訊息，或一些json格式的報文，在報文裡再附上真正的狀態碼。
但是看了一些別人的接口，有人是直接回傳510狀態碼。
請問，各位有何高見？哪種才是規範？
假設，客戶端發送了一個請求到伺服器，伺服器驗證資料後，發覺不符合，需要回傳一個錯誤。
我理解是，客戶端由於請求過程是正確的，所以即使資料格式不符合服務端的要求，服務端也應該返回200狀態碼，然後在正文裡帶回錯誤訊息，或一些json格式的報文，在報文裡再附上真正的狀態碼。
但是看了一些別人的接口，有人是直接回傳510狀態碼。
請問，各位有何高見？哪種才是規範？
很多網路上那些接口，大多是不符合規範的，說白了就是一群連 HTTP 協定都不懂的人寫的 HTTP 服務，毫無參考價值。所以不要糾結那些。為什麼 PHP 招黑和這個原因類似，很感激你願意深究這個問題，為你這種精神必須點讚。
其實我建議你購買此書：《HTTP 權威指南》，很適合你這種有上進心的人。
對於這個問題，實際上你的理解有偏差。
請求過程正確不意味著回應就應當是 200。因為能夠獲得回應，就已經說明請求 過程 是沒有任何問題的，若是請求過程不正確，不是 DNS 異常就是連接超時等等，你連響應碼都看不到的。
所以回應碼是用來識別 HTTP 伺服器收到請求後，對此回應給出的結果。
為此，主要 劃分了2xx、3xx、4xx、5xx 這幾種，2 打頭的肯定是成功（不僅僅是200 哦），3 開頭的往往是無異常，但可能資源不是直接從你這個請求獲取的，例如302 重定向，304 快取未過期等等。
重點來了，4 打頭的，往往是請求存在異常，例如你所謂的提交的資料格式不正確400 或422，請求需要授權的401，因為某種原因（權限不足或黑名單）導致的拒絕用403，請求的資料不存在或該資料不想被目前請求獲取用404（很熟悉吧），請求方法被拒絕用405，例如修改資料應該用PUT 請求、新增資料用POST，取得資料用GET，刪除資料用DELETE 請求等等（還有常見的OPTIONS 和HEAD 請求哦），當然，4 開頭的回應碼最多，可以在百科（不論啥百科）都有HTTP 狀態碼的詳細文章。
5 開頭的主要是伺服器錯誤，不是因為請求的錯誤造成的異常都是用 5 開頭的狀態碼，例如 500 伺服器異常、503 伺服器無法提供服務。
HTTP 狀態碼是在 RFC 一系列標準檔案中定義的，因此無法完全適應所有的介面提示細節，但已經能夠完全涵蓋大部分回應的語義。對於細節提示，介面回應中往往會單獨在設定一個狀態回應碼，用來彌補 HTTP 狀態碼對於細節問題的表現力不足的情況。例如都是請求格式錯誤，但是缺少某個參數和參數給多了，都是400，如果想要讓客戶端清楚地知道發生了什麼，你還需要在介面中額外定義一些東西，輔助這類情況。
這個問題其實是要結合具體應用場景。
首先，如果你的客戶端是指App，尤其是手機App，使用200再加上特定錯誤碼的形式是正確的選擇！並不是這樣比較合理，而中國（嗯，其實國外也有）有個國情叫 HTTP 劫持。 404或500有可能直接被業者或其它（呵呵）劫持掉。你回傳的任何附加http錯誤訊息內容，App都將無法接收。所以你看A廠B廠T廠的公網協定都會以這個方式傳遞錯誤，並非設計師或架構師不懂什麼叫Restful與HTTP狀態碼。
如果是內部協議，服務對服務，在保證環境的情況下，你盡可以以標準的，Restful形式定義錯誤。
哦，分享你張圖，如果你有條件且更青睞標準HTTP狀態碼形式的錯誤協定。
規範各種各樣各有各的理，你說的兩種狀態碼一種是以http請求為主參照來分析狀態碼，另一種是以自己接口為主參考來分析狀態碼。兩種都有自己的理由，看使用場景吧
規範嗎，還是跟著公司走~，個人比較喜歡用http狀態碼回傳錯誤並帶上錯誤訊息。
你的是錯誤的，雖然不是200 狀態碼，但是其餘的狀態碼也是可以帶上相應的內容也可以有json，不知道你有沒有用過spring mvc，貌似在4.xx 的時候有的這個功能，只要是用校驗的都會回傳400狀態碼，並回傳json。
這個得看你們專案之中是怎麼規範的！你可以按照http的方式來，也可以自己去設定！比如說，你接受到了這個錯誤狀態碼，然後自己設定一個新的狀態碼，然後順帶回傳一些訊息提示就行了！
看需求而定,專案整體規範為準,如果你個人為專案主導,也可以你為準
參考騰訊的微信開發文件說明.
都是統一的介面回傳值
http status code 基本上都是200.
用不同的error_code來定義錯誤.
個人覺得
510 不了解，說我常寫的狀態碼。
http status 400 和 403。
前者代表請求無法解析，一般多是參數有問題，而且多數時候這個錯誤是不需要寫程式碼判斷，伺服器程式會自動判斷並回傳這個狀態。
例如 我參數只允許傳1-10之間的數，如果使用者瞎傳我就會回傳這個狀態碼。
後者的意思是使用者沒有權限訪問，這種錯誤除了部分在配置裡設定的禁止訪問的路徑外，很多時候需要寫程式碼進行權限判斷。
例如我的後台只允許 某些特定ip和帶有特定請求頭的機器訪問，其他機器全部返回這個狀態碼。
如果改用200 + json回傳 狀態碼，那http這些標準的狀態碼的意義基本上沒用。那設計者早就把他簡化的只剩下200和404了。連404也可以用 json 狀態碼，只用200表示連通沒連通即可。
現代的瀏覽器和搜尋引擎爬蟲都會識別 和部分處理http狀態碼
舉例：
4xx 的狀態碼表示當前這個url不對，沒有再次發送請求的意義。
如果你某頁回傳的是 http 200 + json 400 表示 他參數有問題。
搜尋引擎 不會去解析你的自訂狀態碼，自然會將本條資料錯誤的收錄。
某些使用者透過搜尋引擎會跳到這個參數不正確的頁面。
瀏覽器 同樣不會去解析你的自訂狀態碼， 瀏覽器會自動記錄你的訪問記錄，而瀏覽器接到400、403和404之類的狀態碼是不會保存瀏覽記錄（ chrome是這樣，其他的好像也差不多吧）。
而你返回200後，用戶輸入網址時有很高的機率會點擊瀏覽器的提示記錄，結果又一次訪問了錯誤的連接。
