寫API接口返回狀態(tài)碼的問題

響應(yīng)體組成

公共響應(yīng)代碼

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

....

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

其實(shí)這個(gè)還是看團(tuán)隊(duì)吧，比如最近寫的一個(gè)Api，我前期定義錯(cuò)誤返回碼：

$map = [
    -1001 => '用戶名不存在',
    -1002 => '密碼錯(cuò)誤',
    -1003 => '驗(yàn)證碼錯(cuò)誤'
];

采用定義一個(gè)這樣map錯(cuò)誤碼，1 001，1代表模塊，001代表錯(cuò)誤碼。只是前臺(tái)那里只要你不是返回200（約定成功返回200），其他一律都認(rèn)定錯(cuò)誤返回碼。其實(shí)通過200（成功），-200（不成功）這種簡單的也可以，因?yàn)槟阏埱蟪霈F(xiàn)的異常錯(cuò)誤，肯定是在同一個(gè)模塊下的報(bào)錯(cuò)，所以排查起來也不是很麻煩。

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

-100 => '請重新登陸'

這樣。

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

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

我的設(shè)計(jì)方案是：

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

說明：

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

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

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

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

說明：

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

使用經(jīng)驗(yàn)：

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

我贊成方案二

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

code認(rèn)為是一個(gè)固定的錯(cuò)誤id

第一種的話，成了msg+code共同表示一個(gè)錯(cuò)誤了

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

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

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