響應體組成

公共響應代碼

除了業(yè)務響應代碼，應該還有一些公共響應代碼

....

其實合適的就是好的方案。比如有的項目接口都很簡單，不過就是普通的增刪改查，沒啥復雜邏輯，錯誤定位簡單。前端也不需要告訴用戶后端的具體錯誤內(nèi)容，就簡單提示操作出錯、失敗就可以了。那么狀態(tài)碼可以很簡單，甚至0，1就夠了。 大型的項目就需要一開始把各個模塊的狀態(tài)碼定義好，方便定位捕捉各種錯誤類型。

其實這個還是看團隊吧，比如最近寫的一個Api，我前期定義錯誤返回碼：

$map = [
    -1001 => '用戶名不存在',
    -1002 => '密碼錯誤',
    -1003 => '驗證碼錯誤'
];

采用定義一個這樣map錯誤碼，1 001，1代表模塊，001代表錯誤碼。只是前臺那里只要你不是返回200（約定成功返回200），其他一律都認定錯誤返回碼。其實通過200（成功），-200（不成功）這種簡單的也可以，因為你請求出現(xiàn)的異常錯誤，肯定是在同一個模塊下的報錯，所以排查起來也不是很麻煩。

一些特殊的狀態(tài)碼，肯定是要約定好的。如token過期需要重新登陸

-100 => '請重新登陸'

這樣。

對于前段來說第一種比較方便

我是 成功返回0 提示類的 錯誤返回1 需特殊處理的case返回其他數(shù)字

我的設計方案是：

code: 狀態(tài)碼
summary: 說明
data: 數(shù)據(jù)
key: 參數(shù)加密
timestamp: 時間戳
nonce: 非重復隨機值

說明：

• code：狀態(tài)碼，使用字符串

  • 數(shù)字容易重復，并且不容易記住，調(diào)試的時候經(jīng)常需要翻文檔，后來改成字符串，比如：failure_password_or_account_error，這種具有自說明性的狀態(tài)碼，并且不容易重復
  • 成功的時候統(tǒng)一success。其他狀態(tài)碼全局唯一但是各個接口可能會出現(xiàn)相同狀態(tài)碼。
  • 如果有業(yè)務狀態(tài)不一致的地方比如do_something_1、do_something2等。
  • 還有一些需要全局捕捉的錯誤碼，比如login_status_timeout，登錄過期......

• summary：說明，是對狀態(tài)碼的說明，一般是中文，

  • 便于調(diào)試，
  • 也可以作為文案，讓前端直接顯示，比如failure_password_or_account_error，前端不需要捕捉這個錯誤，而直接提示summary，此時sumamry的內(nèi)容是賬戶或者密碼錯誤，這樣前端就不需要捕捉每個狀態(tài)碼，只需要捕捉特定的的就好了。
  • 還能防止新的錯誤碼出現(xiàn)前端沒有捕捉，補充空白文案。比如后端突然、或者前端沒有捕捉一個錯誤碼error_yo_yo:異地登錄，請重新登錄，這時候前端暫時不捕捉也沒事，畢竟默認就把summary提示出來了，所以用戶就會看到異地登錄，請重新登錄的提示，雖然跳到登錄頁面更好，但是暫時也不影響用戶操作。
• data：這是真正的數(shù)據(jù)，需要的時候就返回
• key：對data的加密，用來校驗參數(shù)是否被篡改
• timestamp：時間戳，可用來加密data入?yún)ⅲ瑫r給后端校驗
• nonce：無意義隨機字符串，配合timestamp防重放攻擊

說明：

上面的流程直接封裝成網(wǎng)絡層，配合模型層，上層的業(yè)務幾乎感覺不到這里的繁雜的東西，對上層來說，該捕捉狀態(tài)碼的時候，直接捕捉，不需要捕捉的時候，甚至都不用理會。將細節(jié)屏蔽、擴展能力擴大才是最優(yōu)的

使用經(jīng)驗：

這一套使用了大概2年，也經(jīng)過好幾次改版和迭代，橫跨了十多個項目，涉及原生安卓、ios、js 等，雖然上面有很多細節(jié)沒有說的很清晰，但是也差不多了。

我贊成方案二

msg可以認為是一種服務端下發(fā)的提示文案。

code認為是一個固定的錯誤id

第一種的話，成了msg+code共同表示一個錯誤了

更傾向于第二種，并且也建議直接用第二種，也是系統(tǒng)優(yōu)化茁壯的必然選擇。
樓上有人說對前端方便與否的，其實都一樣，正確狀態(tài)碼就一個 0,1,200 視自己習慣而定，其他都是錯誤碼，像我習慣0是success，其他都是異常，而對前端來說無非是判斷是0還是1與判斷是0還是非0的區(qū)別 實在想不通這算什么麻煩？
采用第二種方案后端給出詳細錯誤code能使錯誤信息更精準，嫌麻煩無意義的直接當成0和1用統(tǒng)一錯誤提示即可，也就是說第二種方案是可以向第一種無縫兼容的。
但一但決定采用第一種方案，后端只給你一種錯誤code,你以后后端想改第二種的話那代碼量就可觀了

第一種。
雖然第二種更具體，但是實際上并不一定有啥用，對于用戶來說，密碼不正確或者用戶名不存在反正都是錯誤，前臺要那code并沒啥用。
不過如果不是前后端分離情況的話，光code和msg是不夠用的，最好加一個url字段，用于前臺是否需要跳轉(zhuǎn)。

第三種方式，比如errcode值為10000的時候表示成功，其他情況下比如111021的含義會拆分成“1”，“11”，“021”這樣去解讀。第一個1表示模塊如index、wap、api等模塊。第二個11表示模塊下的方法，最后一個021表示錯誤的行數(shù)。方便問題排查吧。
個人覺得習慣哪種用哪種，沒有啥是必須遵守的。