產(chǎn)品經(jīng)理須知 | API接口知識(shí)小結(jié)

9 評(píng)論 28460 瀏覽 404 收藏 14 分鐘

隨著產(chǎn)品職能的逐步細(xì)分,中后臺(tái)產(chǎn)品經(jīng)理,尤其是負(fù)責(zé)開放平臺(tái)相關(guān)的,日常工作主要是圍繞API接口進(jìn)行,所以更是需要能理解API接口,因?yàn)榻涌诘穆毮苁窍到y(tǒng)的輸出表現(xiàn)。本文就關(guān)于產(chǎn)品經(jīng)理需要了解的接口相關(guān)知識(shí)進(jìn)行小結(jié)。

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

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

常見web接口是http/https協(xié)議的接口,多用于外部系統(tǒng)或前端系統(tǒng)的調(diào)用,因?yàn)榇祟惤涌诘刂芬┞对谕獠?,所以必須?duì)接口的安全性做較高程度的校驗(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接口為例展開的討論。

一、接口請(qǐng)求方式類型

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

1)get類型接口

格式:請(qǐng)求數(shù)參數(shù)寫在網(wǎng)址后面,用”?”連接,多個(gè)參數(shù)之間用”&”連接。

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

2)post型接口

說明:向指定資源位置提交數(shù)據(jù)(如提交表單、上傳文件)來進(jìn)行請(qǐng)求,post請(qǐng)求可能會(huì)導(dǎo)致新資源的建立。

場(chǎng)景:如注冊(cè)、上傳、發(fā)帖等功能,這種請(qǐng)求數(shù)據(jù)量大,安全性要求高。

其他接口類型如put(改)、delete(刪)、patch等使用評(píng)率稍低一些,此處不再贅述。

二、接口響應(yīng)機(jī)制類型

從返回上區(qū)分,分為 同步接口、異步接口

1)同步交互

指發(fā)送一個(gè)請(qǐng)求,需要等待返回,然后才能夠發(fā)送下一個(gè)請(qǐng)求,有個(gè)等待過程;

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

2)異步交互

指發(fā)送一個(gè)請(qǐng)求,不需要等待返回,隨時(shí)可以再發(fā)送下一個(gè)請(qǐng)求,即不需要等待。

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

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

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

三、接口的觸發(fā)形式類型

1)分發(fā)接口

一個(gè)系統(tǒng)產(chǎn)生新數(shù)據(jù)的時(shí)候就分發(fā)給其它系統(tǒng)(也可以是多個(gè))。

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

2)訂閱接口

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

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

四、其他API接口基本組成

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

1)應(yīng)用場(chǎng)景

顧名思義,此接口適用于的場(chǎng)景,明確接口的業(yè)務(wù)用途。

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

入?yún)⑹墙涌谡?qǐng)求所需要的變量參數(shù),其中包括必填參數(shù)和非必填參數(shù),非必填并非是可以忽略的,比如上面的入?yún)⒅?,簽名類型為非必填,如果未傳此參?shù),則默認(rèn)此簽名類型為MD5,如果使用的并非此類簽名類型,則此項(xiàng)為必填項(xiàng)。如果是普通訂單查詢,入?yún)r(shí)間非必填,則返回結(jié)果是用戶全部訂單,或者用戶特定時(shí)間訂單的區(qū)別。

3)錯(cuò)誤碼

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

五、接口安全性校驗(yàn)

接口完成業(yè)務(wù)邏輯開發(fā)后,接下來要考慮的就是安全性問題了,接口的安全性問題主要來源于幾方面考慮:

1)請(qǐng)求來源是否合法?

即接口的偽裝攻擊,因?yàn)榻涌谑菍?duì)外的,在公網(wǎng)環(huán)境中,接口地址是暴露的,收到的請(qǐng)求有可能是惡意非法請(qǐng)求;如果真的是合法請(qǐng)求,也需要知道這個(gè)請(qǐng)求的來源,同時(shí)這個(gè)請(qǐng)求來源不能否認(rèn)。這里引入“簽名”的概念,以及簽名的防偽裝及抗否認(rèn)性特性。

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

2)請(qǐng)求是否會(huì)被篡改,返回?cái)?shù)據(jù)可能會(huì)被截取

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

DES(Data Encryption Standard):數(shù)據(jù)加密標(biāo)準(zhǔn),速度較快,適用于加密大量數(shù)據(jù)的場(chǎng)合;

3DES(Triple DES):是基于DES,對(duì)一塊數(shù)據(jù)用三個(gè)不同的密鑰進(jìn)行三次加密,強(qiáng)度更高;

RSA:非對(duì)稱加密,由 RSA公司發(fā)明,是一個(gè)支持變長(zhǎng)密鑰的公共密鑰算法,需要加密的文件塊的長(zhǎng)度也是可變的;既可以實(shí)現(xiàn)加密,又可以實(shí)現(xiàn)簽名。

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

3)如何防范接口的重放攻擊,防重放攻擊是什么呢?

就是把你的請(qǐng)求原封不動(dòng)地多次發(fā)放,請(qǐng)求都會(huì)通過驗(yàn)證進(jìn)入到正常邏輯中,會(huì)造成服務(wù)端接口擁堵并且會(huì)造成實(shí)際損失。

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

六、接口性能相關(guān)

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

1)TPS

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

2)RT

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

3)吞吐量

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

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

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

七、接口需要做哪些測(cè)試

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

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

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

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

 

本文由 @椒圖 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。

題圖來自Unsplash,基于CC0協(xié)議。

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 可以轉(zhuǎn)載嗎

    回復(fù)
  2. 學(xué)習(xí)到了,很基礎(chǔ)但是很有用,解開了很多直接接觸接口但是引發(fā)了困惑的問題。

    來自安徽 回復(fù)
  3. 并發(fā)跟tps有什么區(qū)別哇?

    來自廣東 回復(fù)
  4. 謝謝科普 ?? (另用戶領(lǐng)取優(yōu)惠卷寫出用戶領(lǐng)導(dǎo)了)

    來自廣東 回復(fù)
  5. tps和qps 抱歉打錯(cuò)了

    來自北京 回復(fù)
  6. 請(qǐng)問tps有什么區(qū)別

    來自北京 回復(fù)
    1. tps是并發(fā)指標(biāo),比如隨便開發(fā)的一個(gè)接口不可能承受天貓雙11流量,它是整個(gè)鏈路的最小值

      回復(fù)
  7. 目前看到最詳細(xì)的解讀了

    來自廣東 回復(fù)
  8. 很清晰,學(xué)習(xí)到了

    回復(fù)