自己記錄一下
推薦：版本 1 ：
成功執行： head status code:2xx
失敗執行 head status code:4xx-5xx
}版本 2 ：
成功和失敗執行 head status code:2xx
json }
--------------------------嗯，分割線--------------------------
微軟規範簡單截圖，成功json，成功陣列，失敗
---------------------還是我-----------------------
阿里和我遇到的公司，都是統一code data msg
但是業務跟404 500混一起用，確實不合理，成功了code沒啥用，msg更沒用，data只有當返回是陣列時有用，所以code data msg應該改為status，微軟是這樣的
還是推薦第一種
1、返回json，成功就返回該json
2、返回array，成功就返回該陣列，並套外層節點，如圖2
3、返回error，就返回}，乙個節點知道是錯誤就行了，反正前端或者對接方也看不懂、用不了另一端的錯誤資訊
4、如返回有狀態用於業務判斷，可統一叫status
5、可用data.error == null判斷是否呼叫成功
前後端分離 JSON
json是乙個輕量級的資料交換格式,對於前後端分離的時代，json在這裡面起著非常大的作用。json在後端中常用的用法 json responsebody public string json1 需要注意的是，這個返回物件會出現亂碼，這裡有兩種解決方法。2.在spring mvc中配置 json格式...
API 前後端分離重構
背景 後端出現大量前端 造成邏輯不清晰，可讀可維護性差。前端採用原始的jquery開發，前端技術已經遠遠落後於市面主流技術，造成開發效率低，混亂。解決 採用主流前後端分離技術，包括 1.前端路由做流程控制 2.使用mvvm框架 做資料繫結 等等 效果 後端只寫介面，很多任務作遷到前端，前後端語言各司...
關於API，前後端分離
而關於介面的規定，衍生出了一大堆問題，第一是關於空值的制定，是不輸出呢？還是輸出null，還是輸出 今天在除錯1688開放平台時，1688開放平台那邊出了兩套介面api給我們調，一套是舊的，用關鍵字deprecated標誌過時，而一套是新的，因為是最近才推出的吧。有點坑的是，新介面雖然變得簡潔了，但...