整體規範建議採用restful方式來實施。
協議：api與使用者的通訊協議，應該使用https協議，確保互動資料的安全傳輸。
網域名稱：應該盡量將api部署在專用網域名稱下。如：
api版本控制：
方法一：將api的版本號放入uri，如：
方法二：將版本號放在http頭資訊中。這種方法不如放入url中方便和直觀。
採用多版本並存，增量發布的方式，vn代表版本號，分為整形和浮點型。
整形的版本號：大功能發布的版本，改動比較多。
浮點型：小版本號，只增加或修改了很小一部分東西。
http請求方式：
對於資源的具體操作型別，由http的動詞表示。
常用的http動詞有下面四個（括號裡是對應的sql命令）。
get（select）：從伺服器取出資源（一項或多項）。
post（create）：在伺服器新建乙個資源。
put（update）：在伺服器更新資源（客戶端提供改變後的完整資源）。
delete（delete）：從伺服器刪除資源。
下面是一些例子。
get /product：列出所有商品
post /product：新建乙個商品
get /product/id：獲取某個指定商品的資訊
put /product/id：更新某個指定商品的資訊
delete /product/id：刪除某個商品
get /product/id/purchase ：列出某個指定商品的所有投資者
get /product/id/purchase/id：獲取某個指定商品的指定投資者資訊
返回資料
只要api介面成功接到請求，就不能返回200以外的http狀態。
為了保障前後端的資料互動的順暢，建議規範資料的返回，並採用固定的資料格式封裝。
介面返回模板：
||,msg:』』
}status: 介面的執行的狀態:
=0表示成功
<0 表示有異常=""
data 介面的主資料可以根據實際返回陣列或json物件
msg:
當status!=0 都應該有錯誤資訊
由於實際業務開展過程中，可能會出現各種的api不是簡單的restful 規範能實現的，因此，需要有一些api突破restful規範原則。特別是移動網際網路的api設計，更需要有一些特定的api來優化資料請求的互動。
頁面級的api
把當前頁面中需要用到的所有資料通過乙個介面一次性返回全部資料
舉例api/v1/get-home-data 返回首頁用到的所有資料
這類api有乙個非常不好的位址，只要業務需求變動，這個api就需要跟著變更。
自定義組合api
把當前使用者需要在第一時間內容載入的多個介面合併成乙個請求傳送到服務端，服務端根據請求內容，一次性把所有資料合併返回,相比於頁面級api，具備更高的靈活性，同時又能很容易的實現頁面級的api功能。
傳入引數：
data:[
},},},}
]返回資料,},
},,]}
API 介面開發規範
api與使用者的通訊協議，總是使用https協議，確保互動資料的傳輸安全。應該盡量將api部署在專用網域名稱之下。如果確定api很簡單，不會有進一步擴充套件，可以考慮放在主網域名稱下。應該將api的版本號放入url。v 另一種做法是，將版本號放在http頭資訊中，但不如放入url方便和直觀。gith...
介面規範 API介面
同通過網路，規定前後臺資訊互動規則的url連線，是前後臺資訊互動的媒介。1 url 2 請求方式 get post put patch delete 3 請求引數 json或xml格式的key value型別資料 4 響應結果 json或者xml格式的資料 編寫介面文件可以使用去哪網技術中心的乙個開...
API介面規範
對於資源的具體操作型別，由http動詞表示。常用的http動詞有下面四個 括號裡是對應的sql命令 get select 從伺服器取出資源 一項或多項 post create 在伺服器新建乙個資源。put update 在伺服器更新資源 客戶端提供改變後的完整資源 delete delete 從伺服...