客戶端請求api，通常需要通過返回碼來判斷api返回的結果是否符合預期，以及該如何處理返回的內容等
相信很多同學都吃過返回碼定義混亂的虧，有的api用返回碼是int型別，有的是string型別，有的用0表示成功，又有的用1表示成功，還有用」true」表示成功，碰上這種事情，只能說：頭疼
api返回碼的設計還是要認真對待，畢竟好的返回碼設計可以降低溝通成本以及程式的維護成本
以http狀態碼為例，為了更加清晰的表述和區分狀態碼的含義，http狀態做了分段。
分段分段描述
1xx資訊，伺服器收到請求，需要請求者繼續執行操作
2xx成功，操作被成功接收並處理
3xx重定向，需要進一步的操作以完成請求
4xx客戶端錯誤，請求包含語法錯誤或無法完成請求
5xx伺服器錯誤，伺服器在處理請求的過程中發生了錯誤
對於後端開發來說，我們通常見到的都是：
2xx狀態碼，比如200->請求成功，
5xx狀態碼，比如502->伺服器異常，通常就是服務沒正常執行，或者**執行出錯
通過狀態碼即可初步判斷問題原因，http狀態的設計思路值得借鑑。
雖說是返回碼設計，但是只有code是不行的，還要有對應的message，讓人可以看懂
字段型別
說明code
int返回碼
message
string
返回碼說明
參考http狀態碼的思路，我們對錯誤碼進行分段
返回碼值說明0
成功99999
系統發生未知異常
10000-19999
引數校驗錯誤
20000-29999
a步驟執行失敗
30000-39999
b步驟執行失敗
通過這樣的設計，不論是程式還是人都可以非常方便的區分api的返回結果，關鍵是統一！
通常我們的message都是寫給工程師看的，但是在不同的場景下，同樣的錯誤，可能需要給使用者看到不一樣的錯誤提示。
比方說 20000-29999表示訂單建立失敗：
這兩種錯誤情況如果是給使用者看，可能就只適合看到：很抱歉，您有乙個正在進行中的訂單，請到我的訂單列表中處理。
但是對於api來說，返回的資訊又必須是準確的，但使用者看到的就必須轉譯，這個轉譯的工作呼叫方可以做，但是通常api提供者來提供個性化的message能力會更好
我們可以把轉譯的訊息配置到資料庫，並快取到redis或者api本機
code
message
100001
20001
很抱歉，您有乙個正在進行中的訂單，請到我的訂單列表中處理。
100001
20002
很抱歉，您有乙個正在進行中的訂單，請到我的訂單列表中處理。
有了統一的code，我們就可以通過nginx或者apm工具統計api請求code數量及分布資訊。
我們可以根據單位時間內99999的數量來做api的異常告警
我們可以根據code的返回餅圖，幫助我們發現系統、業務流程中的問題
等等總之，好的返回碼設計，可以幫助我們提高溝通效率，降低**的維護成本
http返回錯誤碼
http響應碼響應碼由三位十進位制數字組成，它們出現在由http伺服器傳送的響應的第一行。響應碼分五種型別，由它們的第一位數字表示 1xx 資訊，請求收到，繼續處理 2xx 成功，行為被成功地接受 理解和採納 3xx 重定向，為了完成請求，必須進一步執行的動作 4xx 客戶端錯誤，請求包含語法錯誤或...
API錯誤碼對照表
本對照表借鑑自微博api 錯誤 宣告2 0502 服務級錯誤 1為系統級錯誤 服務模組 具體錯誤 系統級錯誤 錯誤 錯誤資訊 詳細描述 10001 request api not found 介面不存在 服務級錯誤 錯誤 錯誤資訊 詳細描述 20001 data does not exists 資料...
C 異常2 返回錯誤碼
一種比異常終止更靈活的辦法是，使用函式的返回值來指出問題。例如，ostream類的get void 成員通常返回下乙個輸入字元的ascii碼，但到達檔案尾時，將返回eof。對hmean 來說，這種方法不管用。任何數值都是有效的返回值，因此不存在可以指出問題的特殊值。在這種情況下，可以使用指標引數或引...