API接口知識小結

應用程序接口API（Application Programming Interface），是提供特定業務輸出能力、鏈接不一樣系統的一種約定。這裏包括外部系統與提供服務的系統（中後臺系統）或後臺不一樣系統之間的交互點。包括外部接口、內部接口，內部接口又包括：上層服務與下層服務接口、同級接口。

本文站在產品經理角度由淺入深講述接口相關知識。若是不想被視爲技術大佬眼中什麼都不懂的需求搬運工，清楚接口的相關知識是頗有必要的。

常見web接口是http/https協議的接口，多用於外部系統或前端系統的調用，由於此類接口地址要暴露在外部，因此必須對接口的安全性作較高程度的校驗。還要一種基於開源rpc構建的跨系統接口調用接口方案，此類主要用於大公司內網各系統間的互相調用，此類接口服務治理能力更強，接口相應速度更塊。如下內容以http接口爲例展開的討論。

1、接口請求方式類型
常見的http請求方式包括：get（查）、post（增），除此以外還有put（改）、delete（刪）等。接口所屬類型是由業務決定的。好比你打開淘寶，展現的首頁內容就須要用到get接口，獲取頁面信息，你看中了寶貝要下單，添加你的收穫地址時，用的則是post接口。而這兩種也是其中最多見的兩種接口類型

1）get類型接口
格式：請求數參數寫在網址後面，用」?」鏈接，多個參數之間用」&」鏈接。

場景：get型接口用於獲取信息，多用於查詢數據，如菜單列表展現，搜索展現，訂單查詢，優惠券查詢等須要其餘系統返回數據時使用。通常狀況下請求的數據量較小，返回速度快，不過接口是暴露在外面的，因此會有必定的風險。

2）post型接口
說明：向指定資源位置提交數據（如提交表單、上傳文件）來進行請求，post請求可能會致使新資源的創建。

場景：如註冊、上傳、發帖等功能，這種請求數據量大，安全性要求高。

其餘接口類型如put（改）、delete（刪）、patch等使用評率稍低一些，此處再也不贅述。

2、接口響應機制類型
從返回上區分，分爲 同步接口、異步接口

1）同步交互
指發送一個請求,須要等待返回,而後纔可以發送下一個請求，有個等待過程；

好比登陸接口，執行登陸操做時，將用戶名、密碼、token等字段加密後經過接口校驗，須要返回驗證結果後，才能登陸成功。

2）異步交互
指發送一個請求,不須要等待返回,隨時能夠再發送下一個請求，即不須要等待。

如用戶領導優惠券，只須要將用戶的領券行爲請求成功，資產系統收到請求後異步操做用戶發券，經過異步的方法執行發券，調用方無須等待每一個請求的調用結果。

區別：一個須要等待，一個不須要等待，在不影響用戶體驗的狀況下，咱們的項目開發中通常會優先選擇不須要等待的異步交互方式。

哪些狀況建議使用同步交互呢？好比用戶登陸、銀行的轉帳系統，對數據庫的保存操做等等，都會使用同步交互操做，其他狀況都優先使用異步交互。

3、接口的觸發形式類型
1）分發接口
一個系統產生新數據的時候就分發給其它系統（也能夠是多個）。

中臺系統的核心思想是高內聚、低耦合，因此分發接口的使用場景仍是比較多的。好比有一個主渠道系統來管理全部的渠道數據，而渠道數據是其餘系統如商品系統、促銷系統常常要使用到的信息。因此一旦出現新的渠道或者發生渠道變動，須要分發給其餘全部對接了各個系統，實現對最新渠道的功能支撐。

2）訂閱接口
一個系統在須要的時候調用其餘系統的接口進行數據訂閱。

好比訂單系統生成訂單時，由於不少外部系統可能須要及時獲取訂單狀態信息。而訂單系統也不知道要分發給哪些系統，這時候通常會將訂單推送至特定的消息隊列，好比KFK，其餘由須要跟進訂單狀態的的系統訂閱KFK消息後，能夠即便獲取訂單完成信息，進行觸發下一個動做。

4、其餘API接口基本組成
再既定的業務下，接口請求類型、響應機制等肯定後，再以微信支付API爲例，瞭解下接口的其餘組成內容。

1）應用場景
顧名思義，此接口適用於的場景，明確接口的業務用途。

2）入參及出參

入參是接口請求所須要的變量參數，其中包括必填參數和非必填參數，非必填並不是是能夠忽略的，好比上面的入參中，簽名類型爲非必填，若是未傳此參數，則默認此簽名類型爲MD5，若是使用的並不是此類簽名類型，則此項爲必填項。若是是普通訂單查詢，入參時間非必填，則返回結果是用戶所有訂單，或者用戶特定時間訂單的區別。

3）錯誤碼
接口請求並不是每次都能成功，因此在接口開發時會對可能失敗的狀況進行錯誤碼區分，在接口聯調時能夠根據返回的錯誤碼快遞定位問題。若是錯誤碼不夠全面，那在接口調用失敗的時候，須要反覆定位，下降開發效率。

5、接口安全性校驗
接口完成業務邏輯開發後，接下來要考慮的就是安全性問題了，接口的安全性問題主要來源於幾方面考慮：

1）請求來源是否合法？
即接口的假裝***，由於接口是對外的，在公網環境中，接口地址是暴露的，收到的請求有多是惡意非法請求；若是真的是合法請求，也須要知道這個請求的來源，同時這個請求來源不可否認。這裏引入「簽名」的概念，以及簽名的防假裝及抗否定性特性。

近些年各大企業強制使用https替換掉原有的http接口，正是由於https所使用的的證書安全性更高。

2）請求是否會被篡改，返回數據可能會被截取
由於接口是對外的，因此接收請求和返回數據的時候，是不可能使用明文方式傳輸的，不然一旦被惡意截取，會形成極大風險。因此請求數據及返回數據都是須要加密的，這樣即便數據被截取，也不用泄露數據的內容。這裏介紹幾種如今常見的加密方法。

DES（Data Encryption Standard）：數據加密標準，速度較快，適用於加密大量數據的場合；

3DES（Triple DES）：是基於DES，對一塊數據用三個不一樣的密鑰進行三次加密，強度更高；

RSA：非對稱加密，由 RSA公司發明，是一個支持變長密鑰的公共密鑰算法，須要加密的文件塊的長度也是可變的；既能夠實現加密，又能夠實現簽名。

若是是用戶帳號相關，如今會使用token加密用戶信息，用戶請求身份信息時，服務端會分配token存在緩存中，後續請求會將token與時間戳一塊兒打包加密，這樣即便請求數據被截獲，由於不知道token的值，數據也不會被解析出來。

3）如何防範接口的重放，防重放是什麼呢？
就是把你的請求原封不動地屢次發放，請求都會經過驗證進入到正常邏輯中，會形成服務端接口擁堵而且會形成實際損失。

防重放通常需在請求參數加上 時間戳 + 隨機數，經過時間戳確保接口是最新的請求，而隨機數相同則能夠認定爲是重放***。

6、接口性能相關
若是是訪問量比較大的接口，再上線前確定須要進行壓力測試。由於普通的開發自測和生產模擬是不能推算出高併發時候接口是否可正常運行。

1）TPS
Transaction Per Second 每秒系統處理的交易或事物的數量，衡量系統處理能力的重要指標。

2）RT
響應時間，從客戶端發送一個請求開始，到客戶端接收到從服務器返回的響應結果結束所經歷的時間，包括請求發送時間，網絡傳輸時間和服務器處理時間三部分。

3）吞吐量
指的是在一次性能測試過程當中網絡上傳輸的數據量的總和。

用戶的響應時間自沒必要說，時間過久傷用戶體驗，及時處於高併發期，用戶的響應時間依然須要控制到最低，通常不超過5s；

tps則是高併發的指標，通常提供服務的接口，須要考慮到最極端狀況下的併發數，這些數量通常來自於運營的活動策劃和往期的數據趨勢預估，以此爲依據，保證本身的接口能夠支持最高的併發數，而驗證這些使用的通常是壓力測試。如正常狀況下壓測時tps能夠達到2000時接口正常，就能夠保證2000的實際併發。

7、接口須要作哪些測試
接口測試實際上是白盒測試，首頁要明確系統的能力輸出，明確服務覆蓋是否知足需求。以業務邏輯推接口參數。

1）入參不符合要求須要有明確錯誤碼，報錯信息和日誌，方便問題復現與定位。

2）若是另有參數處理邏輯的鏈路，也須要一併驗證，如購買網易雲音樂會員，訂單生成後會去權益系統加權，加權成功後會有短信通知用戶，但加權接口和訂單信息中都沒有用戶手機號，因此雖然入參中沒有用戶手機號，但須要根據用戶的username去查詢手機號，並執行短信發放的操做。

其餘驗證目標如：代碼覆蓋率是否達到要求、性能指標是否知足要求、安全指標是否知足要求則是更爲專業性的測試指標了。