產(chǎn)品經(jīng)理不需要深入地去了解各個接口的實現(xiàn)原理，畢竟術(shù)業(yè)有專攻，但是了解什么場景應(yīng)該使用什么樣的接口還是很有必要的，可以方便更好地對外提供數(shù)據(jù)服務(wù)。

剛成為產(chǎn)品經(jīng)理的時候常常聽到開發(fā)吐槽：“這產(chǎn)品經(jīng)理啥都不懂，這個需求那么多接口，開發(fā)都夠嗆還要聯(lián)調(diào)，居然就排這么點開發(fā)時間，出了什么問題我可不負(fù)責(zé)！”

每次聽到這樣的吐槽總會一臉懵逼——什么接口？什么聯(lián)調(diào)？我又做錯了什么？

后來自己做過開發(fā)之后，開始了解到：在系統(tǒng)層面上，除了看得到的頁面功能，還有很多隱藏在頁面功能之下的接口。

這篇文章就簡單總結(jié)一下：我眼中的接口是什么樣的？以及，為何要學(xué)習(xí)API接口知識？

API接口：應(yīng)用程序接口（API：Application Program Interface），是一組定義、程序及協(xié)議的集合，通過 API 接口實現(xiàn)計算機軟件之間的相互通信。

打個比方，如果我開了一家銀行，開放了存/取款的服務(wù)。普通儲戶通過手上的支票想取走存款，必須先找到對應(yīng)的【位置】，也就是正確的銀行、正確的柜臺。

按照銀行規(guī)定的【支票格式】填寫好，那么就可以憑這個“支票”里拿走錢。

另外，柜臺是有限的、來取錢的客戶可能會很多，因此也就需要客戶【取號排隊】，一個接著一個有序的進行取款服務(wù)。為了安全和服務(wù)質(zhì)量的考慮，銀行柜臺需要有【反饋機制】，如果客戶支票填寫有誤、或者支票過期了，需要告訴客戶回去重新填寫。

【位置】：系統(tǒng)對外發(fā)布的API地址，包含了IP、端口、API名稱等信息。

【支票格式】：這個接口的數(shù)據(jù)傳輸規(guī)范，比如：SKU只支持9位長度的字符串?dāng)?shù)據(jù)，庫存只支持16位長度的數(shù)字，如果傳參格式不對，那么就會啟動【反饋機制】。

【取號排隊】：接口的“消息隊列”，消息隊列的主要特點是異步處理，可以減少請求響應(yīng)的時間和解耦。想象一下，如果取錢的人不【取號排隊】而是一哄而上涌上柜臺，柜臺還能提供正常的服務(wù)嗎？

【反饋機制】：接口中的返回參數(shù)，為了保證對方能夠正常獲取所有的數(shù)據(jù)，不至于因為數(shù)據(jù)異常之類的原因?qū)е聰?shù)據(jù)丟失，在發(fā)現(xiàn)異常的時候，需要告知對方發(fā)生了什么異常，為什么無法獲取到這個數(shù)據(jù)，對方就會根據(jù)這個反饋做出相應(yīng)的調(diào)整，或者重新發(fā)起請求、或者放棄這種數(shù)據(jù)。

注：開發(fā)人員口中的“聯(lián)調(diào)”，簡而言之就是兩個系統(tǒng)的開發(fā)人員之間對這個接口調(diào)用成功與否、數(shù)據(jù)能否正常獲取等場景進行測試。由于接口聯(lián)調(diào)涉及到跨系統(tǒng)的開發(fā)人員之間配合，所以一般需要在正常的開發(fā)時間之外預(yù)留出一段時間給到開發(fā)人員進行聯(lián)調(diào)。

上面只是用一個比較通俗的例子對接口的原理進行說明，實際上接口的類型有很多，下面會根據(jù)不同的接口類型講講各種類型接口之間的區(qū)別：

同步接口：A系統(tǒng)請求B系統(tǒng)接口之后，必須獲得B系統(tǒng)接口的響應(yīng)后才會執(zhí)行下一步操作。

例如：登錄操作的時候調(diào)用第三方平臺接口（如微信）進行登錄，需要跳轉(zhuǎn)到微信進行驗證并返回驗證結(jié)果后，才能登錄成功。

異步接口：A系統(tǒng)請求B系統(tǒng)接口之后，不需要等待源系統(tǒng)返回結(jié)果就可以進行下一步操作。

例如：在滴滴打車之后，司機點擊結(jié)束行程后，不需要等待銀行付款成功之后再開始下一個訂單。因為此時滴滴已經(jīng)驗證過司機、乘客的銀行賬戶或者支付寶賬戶，確認(rèn)了雙方交易的合法性就可以結(jié)束訂單。

這時，我們看到的是我們已經(jīng)付款成功（其實銀行可能還沒扣款），而滴滴后臺會將這筆交易流水傳給銀行，在銀行驗證后再進行扣款、付款操作。

分發(fā)接口：A系統(tǒng)產(chǎn)生新數(shù)據(jù)的時候就分發(fā)給B系統(tǒng)（也可以是多個）。

例如：電商網(wǎng)站后臺的客戶管理系統(tǒng)，在產(chǎn)生了一個新的黑名單客戶的時候，就會將數(shù)據(jù)分發(fā)到訂單、推薦等等各個系統(tǒng)，以便及時攔截這部分客戶的訂單。

訂閱接口：B系統(tǒng)在需要的時候調(diào)用A系統(tǒng)的接口進行數(shù)據(jù)訂閱。

例如：用戶在股票交易軟件中查詢銀行賬戶余額的時候才會調(diào)用銀行的余額查詢接口，而股票交易軟件自身不存儲這個數(shù)據(jù)。

以上不同類型的接口分別有不同的使用場景，個人認(rèn)為產(chǎn)品經(jīng)理不需要理解各種接口的實現(xiàn)原理，但是要了解什么場景應(yīng)該使用什么樣的接口，以便更好地對外提供數(shù)據(jù)服務(wù)。

個人看來，了解接口有以下幾個好處：

1. 明確各個系統(tǒng)之間的數(shù)據(jù)流轉(zhuǎn)，特別是功能系統(tǒng)的產(chǎn)品經(jīng)理，只有在知道了功能設(shè)計的目的、需要對外提供什么樣的接口服務(wù)，需求設(shè)計階段才能夠考慮得更加全面；

2. 掌握開發(fā)總體工作量，而不局限于功能；另外，在安排項目計劃時能夠考慮到與周邊系統(tǒng)聯(lián)調(diào)的時間，計劃安排才會更加合理；

3. 識別項目中的關(guān)鍵風(fēng)險點，特別是一些關(guān)鍵接口、數(shù)據(jù)量大需要進行大數(shù)據(jù)壓測的接口，需要盡早安排聯(lián)調(diào)和測試，并且對周邊配合的項目提出要求。

在度娘就可以找到不少現(xiàn)成的接口文檔，可以參考騰訊開放平臺上的API列表，這里簡單總結(jié)幾個要點：

1. 聲明接口字段和返回參數(shù)，字段需要聲明是否必填、字段類型、長度以及處理規(guī)則；

2. 聲明接口預(yù)估的數(shù)據(jù)量大小、調(diào)用頻率等，以保證開發(fā)時考慮到接口的健壯性；

3. 聲明接口的異常處理方式，如失敗的數(shù)據(jù)是否重發(fā)、重發(fā)次數(shù)等等。

在之前的產(chǎn)品設(shè)計過程中，還出現(xiàn)過配合系統(tǒng)雙方的產(chǎn)品經(jīng)理為了誰應(yīng)該來寫接口文檔而爭執(zhí)過。后來定了一套標(biāo)準(zhǔn)，個人認(rèn)為是比較合理的，供大家參考：

原則1：一般是由數(shù)據(jù)的需求方來編寫接口需求文檔。

原則2：如果該接口是一個分發(fā)接口，則由數(shù)據(jù)的提供方來編寫接口需求文檔。

好了，說到這里，已經(jīng)把我個人這些年工作中所接觸到的API接口簡單介紹了一下。由于本人一直是做后端產(chǎn)品經(jīng)理，因此對于前端的接口涉獵不多，不了解差異有多大，以上內(nèi)容僅供后端產(chǎn)品經(jīng)理參考，也希望大家能夠?qū)ξ闹械囊恍╁e誤及時指正。

另外，作為一名大數(shù)據(jù)的產(chǎn)品經(jīng)理，大數(shù)據(jù)如何利用接口對外提供服務(wù)？后續(xù)總結(jié)出自己的一套方法論后再分享。