API介面規範(試行版)
1.協議
API與使用者的通訊協議,總是使用HTTPS協議,確保互動資料的傳輸安全。
2.安全
為了保證介面接收到的資料不是被篡改以及防止資訊洩露造成損失,對敏感資料進行加密及簽名。
資料加密
api介面請求引數一律採用RSA進行加解密,在客戶端使用公鑰對請求引數進行加密,在服務端使用對數私鑰據進行解密,防止資訊洩露。
簽名
為了防止請求資料在網路傳輸過程中被惡意篡改,對所有非查詢介面增加數字簽名,簽名原串為對請求引數進行自然排序,通過私鑰加簽後放入sign引數中。
時間戳
api介面中增加時間戳timestamp欄位,作用:固定時間範圍內,減少同一請求被暴力呼叫的次數。
3.API版本控制
API的版本號統一放入URL。
https://api.example.com/v{n}/
v{n}n代表版本號,分為整形和浮點型
整形版本號:大功能版本釋出形式;具有當前版本狀態下的所有API介面,例如:v1,v2
浮點型:為小版本號,只具備補充api的功能,其他api都預設呼叫大版本號的API,例如v1.1,v1.2
4.API路徑規則
在RESTful架構中,每個網址代表一種資源(resource),所以網址中不能有動詞,只能有名詞。名詞儘量與資料庫表格名對應。
例子:
https://api.example.com/v1/products https://api.example.com/v1/users https://api.example.com/v1/employees
5.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:獲取某個指定商品的指定投資者資訊
6.請求資料
公共請求引數
引數名稱 | 引數型別 | 是否必填 | 最大長度 | 描述 | 示例 |
---|---|---|---|---|---|
charset | String | 是 | 10 | 請求使用的編碼格式如:utf-8,gbk | utf-8 |
sign_type | String | 是 | 10 | 生成簽名字串所使用的演算法型別 | RSA |
sign | String | 是 | 344 | 請求引數簽名串 | djdu7dusufiusgfu |
timestamp | String | 是 | 14 | 傳送請求的時間,格式:yyyyMMddHHmmss | 20180505121212 |
requestSource | String | 否 | 8 | 客戶端請求來源APP WAP PC | APP |
token | String | 否 | 鑑權標識,用於登入判斷 | ||
biz_content | String | 是 | 請求引數集合,除公共引數外所有請求引數 |
請求引數(biz_content)
引數名稱 | 引數型別 | 是否必填 | 最大長度 | 描述 | 示例 |
---|---|---|---|---|---|
phone | String | 是 | 10 | 登入手機號 | 15088890908 |
phoneCode | String | 是 | 6 | 驗證碼 | 234567 |
7.返回資料
為了保障前後端的資料互動的順暢,統一介面返回模板如下:
{ code:0000, data:{}, msg:'' }
code:介面的執行狀態
0000:表示成功
其他:不太異常
Data介面的主資料
返回JSON物件
Msg資訊
當code!=0000都應該有錯誤資訊
8.非RESTful API需求
由於實際業務開展過程中,可能會出現各種的api不是簡單的restful規範能實現的,因此需要一些api突破restful規範原則。
8.1頁面級API
把當前頁面中需要用到的所有資料通過一個介面一次性返回全部資料。
例子:
api/v1/get-home-data返回首頁用到的所有資料
此類API存在缺陷:只要業務需求變動,該api就需要跟著變更。
8.2自定義組合API
把當前使用者需要在第一時間內容載入的多個介面合併成一個請求傳送到服務端,服務端根據請求內容,一次性把所有資料合併返回,相比於頁面級API,具備更高的靈活性,同時又能很容易實現頁面級API功能。
規範
地址:api/v1/testApi
傳入引數:
data:[ {url:'api1',type:'get',data:{}}, {url:'api2',type:'get',data:{}}, {url:'api3',type:'get',data:{}}, ]
返回資料
{ code:0000, msg:'', data:[ {code:0000,msg:'',data:[]}, {code:0000,msg:'',data:[]}, {code:0000,msg:'',data:[]}, ] }
9.API共建平臺
RAP是一個GUI的WEB介面管理工具。在RAP中,可定義介面的URL、請求&響應格式等等。通過分析這些資料,RAP提供MOCK服務、測試服務等自動化工具。
9.1什麼是RAP?
在前後端分離的開發模式下,我們通常需要定義一份介面文件來規範介面的具體資訊。如請求地址、有幾個引數、引數名稱及型別含義等等。RAP首先方便團隊錄入、檢視和管理這些介面文件,並通過分析結構化的文件資料,重複利用並生成自測資料、提供自測控制檯等等。
9.2RAP的特色
通過RAP來管理API文件。
提供MOCK服務,通過MockJS建立mock測試資料。