随着産品職能的逐步細分，中後台産品經理，尤其是負責開放平台相關的，日常工作主要是圍繞API接口進行，所以更是需要能理解API接口，因為接口的職能是系統的輸出表現。本文就關于産品經理需要了解的接口相關知識進行小結。

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

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

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

一、接口請求方式類型

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

1）get類型接口

格式：請求數參數寫在網址後面，用”?”連接，多個參數之間用”&”連接。

場景：get型接口用于獲取信息，多用于查詢數據，如菜單列表展示，搜索展示，訂單查詢，優惠券查詢等需要其他系統返回數據時使用。一般情況下請求的數據量較小，返回速度快，不過接口是暴露在外面的，所以會有一定的風險。

2）post型接口

說明：向指定資源位置提交數據（如提交表單、上傳文件）來進行請求，post請求可能會導緻新資源的建立。

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

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

二、接口響應機制類型

從返回上區分，分為 同步接口、異步接口

1）同步交互

指發送一個請求,需要等待返回,然後才能夠發送下一個請求，有個等待過程；

比如登錄接口，執行登錄操作時，将用戶名、密碼、token等字段加密後通過接口校驗，需要返回驗證結果後，才能登錄成功。

2）異步交互

指發送一個請求,不需要等待返回,随時可以再發送下一個請求，即不需要等待。

如用戶領導優惠券，隻需要将用戶的領券行為請求成功，資産系統收到請求後異步操作用戶發券，通過異步的方法執行發券，調用方無須等待每個請求的調用結果。

區别：一個需要等待，一個不需要等待，在不影響用戶體驗的情況下，我們的項目開發中一般會優先選擇不需要等待的異步交互方式。

哪些情況建議使用同步交互呢？比如用戶登錄、銀行的轉賬系統，對數據庫的保存操作等等，都會使用同步交互操作，其餘情況都優先使用異步交互。

三、接口的觸發形式類型

1）分發接口

一個系統産生新數據的時候就分發給其它系統（也可以是多個）。

中台系統的核心思想是高内聚、低耦合，所以分發接口的使用場景還是比較多的。比如有一個主渠道系統來管理所有的渠道數據，而渠道數據是其他系統如商品系統、促銷系統經常要使用到的信息。所以一旦出現新的渠道或者發生渠道變更，需要分發給其他所有對接了各個系統，實現對最新渠道的功能支撐。

2）訂閱接口

一個系統在需要的時候調用其他系統的接口進行數據訂閱。

比如訂單系統生成訂單時，因為很多外部系統可能需要及時獲取訂單狀态信息。而訂單系統也不知道要分發給哪些系統，這時候一般會将訂單推送至特定的消息隊列，比如KFK，其他由需要跟進訂單狀态的的系統訂閱KFK消息後，可以即使獲取訂單完成信息，進行觸發下一個動作。

四、其他API接口基本組成

再既定的業務下，接口請求類型、響應機制等确定後，再以微信支付API為例，了解下接口的其他組成内容。

1）應用場景

顧名思義，此接口适用于的場景，明确接口的業務用途。

2）入參及出參

入參是接口請求所需要的變量參數，其中包括必填參數和非必填參數，非必填并非是可以忽略的，比如上面的入參中，簽名類型為非必填，如果未傳此參數，則默認此簽名類型為MD5，如果使用的并非此類簽名類型，則此項為必填項。如果是普通訂單查詢，入參時間非必填，則返回結果是用戶全部訂單，或者用戶特定時間訂單的區别。

3）錯誤碼

接口請求并非每次都能成功，所以在接口開發時會對可能失敗的情況進行錯誤碼區分，在接口聯調時可以根據返回的錯誤碼快遞定位問題。如果錯誤碼不夠全面，那在接口調用失敗的時候，需要反複定位，降低開發效率。

五、接口安全性校驗

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

1）請求來源是否合法？

即接口的僞裝攻擊，因為接口是對外的，在公網環境中，接口地址是暴露的，收到的請求有可能是惡意非法請求；如果真的是合法請求，也需要知道這個請求的來源，同時這個請求來源不能否認。這裡引入“簽名”的概念，以及簽名的防僞裝及抗否認性特性。

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

2）請求是否會被篡改，返回數據可能會被截取

因為接口是對外的，所以接收請求和返回數據的時候，是不可能使用明文方式傳輸的，否則一旦被惡意截取，會造成極大風險。所以請求數據及返回數據都是需要加密的，這樣即使數據被截取，也不用洩露數據的内容。這裡介紹幾種現在常見的加密方法。

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

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

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

如果是用戶賬号相關，現在會使用token加密用戶信息，用戶請求身份信息時，服務端會分配token存在緩存中，後續請求會将token與時間戳一起打包加密，這樣即使請求數據被截獲，因為不知道token的值，數據也不會被解析出來。

3）如何防範接口的重放攻擊，防重放攻擊是什麼呢？

就是把你的請求原封不動地多次發放，請求都會通過驗證進入到正常邏輯中，會造成服務端接口擁堵并且會造成實際損失。

防重放一般需在請求參數加上 時間戳 随機數，通過時間戳确保接口是最新的請求，而随機數相同則可以認定為是重放攻擊。

六、接口性能相關

如果是訪問量比較大的接口，再上線前肯定需要進行壓力測試。因為普通的開發自測和生産模拟是不能推算出高并發時候接口是否可正常運行。

1）tps

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

2）RT

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

3）吞吐量

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

用戶的響應時間自不必說，時間太久傷用戶體驗，及時處于高并發期，用戶的響應時間依然需要控制到最低，一般不超過5s；

tps則是高并發的指标，一般提供服務的接口，需要考慮到最極端情況下的并發數，這些數量一般來自于運營的活動策劃和往期的數據趨勢預估，以此為依據，保證自己的接口可以支持最高的并發數，而驗證這些使用的一般是壓力測試。如正常情況下壓測時tps可以達到2000時接口正常，就可以保證2000的實際并發。

七、接口需要做哪些測試

接口測試其實是白盒測試，首頁要明确系統的能力輸出，明确服務覆蓋是否滿足需求。以業務邏輯推接口參數。

1）入參不符合要求需要有明确錯誤碼，報錯信息和日志，方便問題複現與定位。

2）如果另有參數處理邏輯的鍊路，也需要一并驗證，如購買網易雲音樂會員，訂單生成後會去權益系統加權，加權成功後會有短信通知用戶，但加權接口和訂單信息中都沒有用戶手機号，所以雖然入參中沒有用戶手機号，但需要根據用戶的username去查詢手機号，并執行短信發放的操作。

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

本文由 @椒圖 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部