上周五，我在做乙個 http 介面的遷移。剛好跟同事進行了一場關於 http 介面的狀態返回的討論。很巧合地是，我們的觀點互不相同，在他看來：
所有業務返回的響應狀態碼都應該是200，包含業務異常的響應狀態碼也是200，錯誤的訊息放在 body 裡面描述；未到達業務層的請求，例如：5xx, 403 這樣的錯誤應該算作是 「連線層」 的錯誤。
這樣做的優點是：
對於 5xx, 403 這樣的錯誤可以歸納為 「連線」 錯誤。可以統一處理？
客戶端只需在接受到 200 的狀態碼時才做業務處理。
但是在我看來，這有乙個很大的缺點：
get /1.1/classes//objectid時，響應的格式是：
response status code: 200
response body: {}
classname與objectid都做成了 path parameter, 通常地，我們不應該用 404 來描述乙個 url 不存在的情況嗎？
如果我要使用這個介面，我在客戶端接收到響應之後大概要做以下的處理：
判斷 http status code 是否是 200。
解析 http body 是否是乙個 error message。
解析 http body 為業務實體。
判斷解析後的業務實體是否是"空"。
所以，我的觀點剛好相反：所有響應的狀態要充分利用 http status code 來描述響應的異常情況， 並且配合 http body 來描述更詳細的 error message。
我同事他認為這樣做的缺點是：
那麼我們該怎麼處理這種 http status code 表達能力不足的情況呢？ 答案是： 使用 http status code 來代表某乙個型別的異常，同時用 http response body 來描述更詳細的異常訊息。 例如：
response status code: 400
response body:
response status code: 400
response body:
bad request， 並且將更加詳細的業務異常表達出來了！ 來看看我如何改造 leancloud 的介面返回：
response status code: 200
response body:
response status code: 404
response body:
可以根據 http status code 判斷響應是否正常。
無需將乙個 response body 適配多個 schema 解析。
客戶端友好，無需過多包裝 response body，在正常返回的情況下資料可以直接使用，無需拆箱。
介面設計可以千變萬化，可以說沒有哪一種方案是完美的，我們在設計的介面的時候也要盡可能地站在使用者的角度考慮下面的原則：
客戶端友好，響應的層次盡可能簡潔。
資料不要過渡封裝，最好能做到即拿即用。
介面名稱簡潔明瞭。
對於 http 介面的更多實踐經驗可以檢視我的文章 restful best practices
介面測試 http狀態碼
http狀態碼 每發出乙個http請求之後，都會有乙個響應，http本身會有乙個狀態碼，來標示這個請求是否成功，常見的狀態碼有以下幾種 1 200 2開頭的都表示這個請求傳送成功，最常見的就是200，就代表這個請求是ok的，伺服器也返回了。2 300 3開頭的代表重定向，最常見的是302，把這個請求...
常見的HTTP異常狀態碼及其含義
常見的http異常狀態碼及其含義 表示要完成請求，需要進一步操作。通常，這些狀態 用來重定向。301 永久移動 請求的網頁已永久移動到新位置。伺服器返回此響應 對 get 或 head 請求的響應 時，會自動將請求者轉到新位置。302 臨時移動 伺服器目前從不同位置的網頁響應請求，但請求者應繼續使用...
HTTP如何儲存使用者狀態
http如何儲存使用者狀態 http是無狀態協議，協議自身不儲存請求和響應的通訊狀態。session機制 session主要作用是通過服務端記錄使用者的狀態。典型場景 購物車。當要新增物品到購物車時，由於http是無狀態協議，系統不知道要加到哪個使用者的購物車裡。服務端給特定的使用者建立特定的ses...