應(yīng)用程序接口API（Application Programming Interface），是提供特定業(yè)務(wù)輸出能力、連接不同系統(tǒng)的一種約定。這里包括外部系統(tǒng)與提供服務(wù)的系統(tǒng)（中后臺系統(tǒng)）或后臺不同系統(tǒng)之間的交互點(diǎn)。包括外部接口、內(nèi)部接口，內(nèi)部接口又包括：上層服務(wù)與下層服務(wù)接口、同級接口。

因?yàn)榕驼嬲\，有更多的客戶和我們聚集在一起，為了共同目標(biāo)，創(chuàng)新互聯(lián)在工作上密切配合，從創(chuàng)業(yè)型企業(yè)到如今不斷成長，要感謝客戶對我們的高要求，讓我們敢于面對挑戰(zhàn)，才有今天的進(jìn)步與發(fā)展。從網(wǎng)站到小程序開發(fā),軟件開發(fā),成都app軟件開發(fā)公司,十余年企業(yè)網(wǎng)站建設(shè)服務(wù)經(jīng)驗(yàn),為企業(yè)提供網(wǎng)站設(shè)計,網(wǎng)站托管一條龍服務(wù).為企業(yè)提供成都全網(wǎng)營銷推廣,按需開發(fā)網(wǎng)站,原創(chuàng)設(shè)計,十余年品質(zhì),值得您的信賴.

本文站在產(chǎn)品經(jīng)理角度由淺入深講述接口相關(guān)知識。如果不想被視為技術(shù)大佬眼中什么都不懂的需求搬運(yùn)工，清楚接口的相關(guān)知識是很有必要的。

常見web接口是http/https協(xié)議的接口，多用于外部系統(tǒng)或前端系統(tǒng)的調(diào)用，因?yàn)榇祟惤涌诘刂芬┞对谕獠?，所以必須對接口的安全性做較高程度的校驗(yàn)。還要一種基于開源rpc構(gòu)建的跨系統(tǒng)接口調(diào)用接口方案，此類主要用于大公司內(nèi)網(wǎng)各系統(tǒng)間的互相調(diào)用，此類接口服務(wù)治理能力更強(qiáng)，接口相應(yīng)速度更塊。以下內(nèi)容以http接口為例展開的討論。

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

1）get類型接口
格式：請求數(shù)參數(shù)寫在網(wǎng)址后面，用”?”連接，多個參數(shù)之間用”&”連接。

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

2）post型接口
說明：向指定資源位置提交數(shù)據(jù)（如提交表單、上傳文件）來進(jìn)行請求，post請求可能會導(dǎo)致新資源的建立。

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

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

二、接口響應(yīng)機(jī)制類型
從返回上區(qū)分，分為 同步接口、異步接口

1）同步交互
指發(fā)送一個請求,需要等待返回,然后才能夠發(fā)送下一個請求，有個等待過程；

比如登錄接口，執(zhí)行登錄操作時，將用戶名、密碼、token等字段加密后通過接口校驗(yàn)，需要返回驗(yàn)證結(jié)果后，才能登錄成功。

2）異步交互
指發(fā)送一個請求,不需要等待返回,隨時可以再發(fā)送下一個請求，即不需要等待。

如用戶領(lǐng)導(dǎo)優(yōu)惠券，只需要將用戶的領(lǐng)券行為請求成功，資產(chǎn)系統(tǒng)收到請求后異步操作用戶發(fā)券，通過異步的方法執(zhí)行發(fā)券，調(diào)用方無須等待每個請求的調(diào)用結(jié)果。

區(qū)別：一個需要等待，一個不需要等待，在不影響用戶體驗(yàn)的情況下，我們的項(xiàng)目開發(fā)中一般會優(yōu)先選擇不需要等待的異步交互方式。

哪些情況建議使用同步交互呢？比如用戶登錄、銀行的轉(zhuǎn)賬系統(tǒng)，對數(shù)據(jù)庫的保存操作等等，都會使用同步交互操作，其余情況都優(yōu)先使用異步交互。

三、接口的觸發(fā)形式類型
1）分發(fā)接口
一個系統(tǒng)產(chǎn)生新數(shù)據(jù)的時候就分發(fā)給其它系統(tǒng)（也可以是多個）。

中臺系統(tǒng)的核心思想是高內(nèi)聚、低耦合，所以分發(fā)接口的使用場景還是比較多的。比如有一個主渠道系統(tǒng)來管理所有的渠道數(shù)據(jù)，而渠道數(shù)據(jù)是其他系統(tǒng)如商品系統(tǒng)、促銷系統(tǒng)經(jīng)常要使用到的信息。所以一旦出現(xiàn)新的渠道或者發(fā)生渠道變更，需要分發(fā)給其他所有對接了各個系統(tǒng)，實(shí)現(xiàn)對最新渠道的功能支撐。

2）訂閱接口
一個系統(tǒng)在需要的時候調(diào)用其他系統(tǒng)的接口進(jìn)行數(shù)據(jù)訂閱。

比如訂單系統(tǒng)生成訂單時，因?yàn)楹芏嗤獠肯到y(tǒng)可能需要及時獲取訂單狀態(tài)信息。而訂單系統(tǒng)也不知道要分發(fā)給哪些系統(tǒng)，這時候一般會將訂單推送至特定的消息隊(duì)列，比如KFK，其他由需要跟進(jìn)訂單狀態(tài)的的系統(tǒng)訂閱KFK消息后，可以即使獲取訂單完成信息，進(jìn)行觸發(fā)下一個動作。

四、其他API接口基本組成
再既定的業(yè)務(wù)下，接口請求類型、響應(yīng)機(jī)制等確定后，再以微信支付API為例，了解下接口的其他組成內(nèi)容。

1）應(yīng)用場景
顧名思義，此接口適用于的場景，明確接口的業(yè)務(wù)用途。

2）入?yún)⒓俺鰠?/p>

入?yún)⑹墙涌谡埱笏枰淖兞繀?shù)，其中包括必填參數(shù)和非必填參數(shù)，非必填并非是可以忽略的，比如上面的入?yún)⒅校灻愋蜑榉潜靥?，如果未傳此參?shù)，則默認(rèn)此簽名類型為MD5，如果使用的并非此類簽名類型，則此項(xiàng)為必填項(xiàng)。如果是普通訂單查詢，入?yún)r間非必填，則返回結(jié)果是用戶全部訂單，或者用戶特定時間訂單的區(qū)別。

3）錯誤碼
接口請求并非每次都能成功，所以在接口開發(fā)時會對可能失敗的情況進(jìn)行錯誤碼區(qū)分，在接口聯(lián)調(diào)時可以根據(jù)返回的錯誤碼快遞定位問題。如果錯誤碼不夠全面，那在接口調(diào)用失敗的時候，需要反復(fù)定位，降低開發(fā)效率。

五、接口安全性校驗(yàn)
接口完成業(yè)務(wù)邏輯開發(fā)后，接下來要考慮的就是安全性問題了，接口的安全性問題主要來源于幾方面考慮：

1）請求來源是否合法？
即接口的偽裝***，因?yàn)榻涌谑菍ν獾模诠W(wǎng)環(huán)境中，接口地址是暴露的，收到的請求有可能是惡意非法請求；如果真的是合法請求，也需要知道這個請求的來源，同時這個請求來源不能否認(rèn)。這里引入“簽名”的概念，以及簽名的防偽裝及抗否認(rèn)性特性。

近些年各大企業(yè)強(qiáng)制使用https替換掉原有的http接口，正是因?yàn)閔ttps所使用的的證書安全性更高。

2）請求是否會被篡改，返回數(shù)據(jù)可能會被截取
因?yàn)榻涌谑菍ν獾?，所以接收請求和返回?shù)據(jù)的時候，是不可能使用明文方式傳輸?shù)?，否則一旦被惡意截取，會造成極大風(fēng)險。所以請求數(shù)據(jù)及返回數(shù)據(jù)都是需要加密的，這樣即使數(shù)據(jù)被截取，也不用泄露數(shù)據(jù)的內(nèi)容。這里介紹幾種現(xiàn)在常見的加密方法。

DES（Data Encryption Standard）：數(shù)據(jù)加密標(biāo)準(zhǔn)，速度較快，適用于加密大量數(shù)據(jù)的場合；

3DES（Triple DES）：是基于DES，對一塊數(shù)據(jù)用三個不同的密鑰進(jìn)行三次加密，強(qiáng)度更高；

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

如果是用戶賬號相關(guān)，現(xiàn)在會使用token加密用戶信息，用戶請求身份信息時，服務(wù)端會分配token存在緩存中，后續(xù)請求會將token與時間戳一起打包加密，這樣即使請求數(shù)據(jù)被截獲，因?yàn)椴恢纓oken的值，數(shù)據(jù)也不會被解析出來。

3）如何防范接口的重放，防重放是什么呢？
就是把你的請求原封不動地多次發(fā)放，請求都會通過驗(yàn)證進(jìn)入到正常邏輯中，會造成服務(wù)端接口擁堵并且會造成實(shí)際損失。

防重放一般需在請求參數(shù)加上 時間戳 + 隨機(jī)數(shù)，通過時間戳確保接口是最新的請求，而隨機(jī)數(shù)相同則可以認(rèn)定為是重放***。

六、接口性能相關(guān)
如果是訪問量比較大的接口，再上線前肯定需要進(jìn)行壓力測試。因?yàn)槠胀ǖ拈_發(fā)自測和生產(chǎn)模擬是不能推算出高并發(fā)時候接口是否可正常運(yùn)行。

1）TPS
Transaction Per Second 每秒系統(tǒng)處理的交易或事物的數(shù)量，衡量系統(tǒng)處理能力的重要指標(biāo)。

2）RT
響應(yīng)時間，從客戶端發(fā)送一個請求開始，到客戶端接收到從服務(wù)器返回的響應(yīng)結(jié)果結(jié)束所經(jīng)歷的時間，包括請求發(fā)送時間，網(wǎng)絡(luò)傳輸時間和服務(wù)器處理時間三部分。

3）吞吐量
指的是在一次性能測試過程中網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)量的總和。

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

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

七、接口需要做哪些測試
接口測試其實(shí)是白盒測試，首頁要明確系統(tǒng)的能力輸出，明確服務(wù)覆蓋是否滿足需求。以業(yè)務(wù)邏輯推接口參數(shù)。

1）入?yún)⒉环弦笮枰忻鞔_錯誤碼，報錯信息和日志，方便問題復(fù)現(xiàn)與定位。

2）如果另有參數(shù)處理邏輯的鏈路，也需要一并驗(yàn)證，如購買網(wǎng)易云音樂會員，訂單生成后會去權(quán)益系統(tǒng)加權(quán)，加權(quán)成功后會有短信通知用戶，但加權(quán)接口和訂單信息中都沒有用戶手機(jī)號，所以雖然入?yún)⒅袥]有用戶手機(jī)號，但需要根據(jù)用戶的username去查詢手機(jī)號，并執(zhí)行短信發(fā)放的操作。

其他驗(yàn)證目標(biāo)如：代碼覆蓋率是否達(dá)到要求、性能指標(biāo)是否滿足要求、安全指標(biāo)是否滿足要求則是更為專業(yè)性的測試指標(biāo)了。