產品經理不需要深入地去了解各個接口的實現原理，畢竟術業有專攻，但是瞭解什麼場景應該使用什麼樣的接口還是很有必要的，可以方便更好地對外提供數據服務。
剛成為產品經理的時候常常聽到開發吐槽：“這產品經理啥都不懂，這個需求那麼多接口，開發都夠嗆還要聯調，居然就排這麼點開發時間，出了什麼問題我可不負責！”
每次聽到這樣的吐槽總會一臉懵逼——什麼接口？什麼聯調？我又做錯了什麼？
後來自己做過開發之後，開始瞭解到：在系統層面上，除了看得到的頁面功能，還有很多隱藏在頁面功能之下的接口。
這篇文章就簡單總結一下：我眼中的接口是什麼樣的？以及，為何要學習API接口知識？
什麼是接口？
API接口：應用程序接口（API：Application Program Interface），是一組定義、程序及協議的集合，通過 API 接口實現計算機軟件之間的相互通信。
打個比方，如果我開了一家銀行，開放了存/取款的服務。普通儲戶通過手上的支票想取走存款，必須先找到對應的【位置】，也就是正確的銀行、正確的櫃檯。
按照銀行規定的【支票格式】填寫好，那麼就可以憑這個“支票”裡拿走錢。
另外，櫃檯是有限的、來取錢的客戶可能會很多，因此也就需要客戶【取號排隊】，一個接著一個有序的進行取款服務。為了安全和服務質量的考慮，銀行櫃檯需要有【反饋機制】，如果客戶支票填寫有誤、或者支票過期了，需要告訴客戶回去重新填寫。
【位置】：系統對外發布的API地址，包含了IP、端口、API名稱等信息。
【支票格式】：這個接口的數據傳輸規範，比如：SKU只支持9位長度的字符串數據，庫存只支持16位長度的數字，如果傳參格式不對，那麼就會啟動【反饋機制】。
【取號排隊】：接口的“消息隊列”，消息隊列的主要特點是異步處理，可以減少請求響應的時間和解耦。想象一下，如果取錢的人不【取號排隊】而是一哄而上湧上櫃臺，櫃檯還能提供正常的服務嗎？
【反饋機制】：接口中的返回參數，為了保證對方能夠正常獲取所有的數據，不至於因為數據異常之類的原因導致數據丟失，在發現異常的時候，需要告知對方發生了什麼異常，為什麼無法獲取到這個數據，對方就會根據這個反饋做出相應的調整，或者重新發起請求、或者放棄這種數據。
注：開發人員口中的“聯調”，簡而言之就是兩個系統的開發人員之間對這個接口調用成功與否、數據能否正常獲取等場景進行測試。由於接口聯調涉及到跨系統的開發人員之間配合，所以一般需要在正常的開發時間之外預留出一段時間給到開發人員進行聯調。
接口的類型有多少種？
上面只是用一個比較通俗的例子對接口的原理進行說明，實際上接口的類型有很多，下面會根據不同的接口類型講講各種類型接口之間的區別：
1. 根據響應的機制可以分為同步、異步接口：
同步接口：A系統請求B系統接口之後，必須獲得B系統接口的響應後才會執行下一步操作。
例如：登錄操作的時候調用第三方平臺接口（如微信）進行登錄，需要跳轉到微信進行驗證並返回驗證結果後，才能登錄成功。
異步接口：A系統請求B系統接口之後，不需要等待源系統返回結果就可以進行下一步操作。
例如：在滴滴打車之後，司機點擊結束行程後，不需要等待銀行付款成功之後再開始下一個訂單。因為此時滴滴已經驗證過司機、乘客的銀行賬戶或者支付寶賬戶，確認了雙方交易的合法性就可以結束訂單。
這時，我們看到的是我們已經付款成功（其實銀行可能還沒扣款），而滴滴後臺會將這筆交易流水傳給銀行，在銀行驗證後再進行扣款、付款操作。
2. 根據接口的觸發形式可以分為分發、訂閱接口
分發接口：A系統產生新數據的時候就分發給B系統（也可以是多個）。
例如：電商網站後臺的客戶管理系統，在產生了一個新的黑名單客戶的時候，就會將數據分發到訂單、推薦等等各個系統，以便及時攔截這部分客戶的訂單。
訂閱接口：B系統在需要的時候調用A系統的接口進行數據訂閱。
例如：用戶在股票交易軟件中查詢銀行賬戶餘額的時候才會調用銀行的餘額查詢接口，而股票交易軟件自身不存儲這個數據。
產品經理瞭解接口有什麼用？
以上不同類型的接口分別有不同的使用場景，個人認為產品經理不需要理解各種接口的實現原理，但是要了解什麼場景應該使用什麼樣的接口，以便更好地對外提供數據服務。
個人看來，瞭解接口有以下幾個好處：
- 明確各個系統之間的數據流轉，特別是功能系統的產品經理，只有在知道了功能設計的目的、需要對外提供什麼樣的接口服務，需求設計階段才能夠考慮得更加全面；
- 掌握開發總體工作量，而不侷限於功能；另外，在安排項目計劃時能夠考慮到與周邊系統聯調的時間，計劃安排才會更加合理；
- 識別項目中的關鍵風險點，特別是一些關鍵接口、數據量大需要進行大數據壓測的接口，需要儘早安排聯調和測試，並且對周邊配合的項目提出要求。
產品經理如何寫接口文檔？
在度娘就可以找到不少現成的接口文檔，可以參考騰訊開放平臺上的API列表，這裡簡單總結幾個要點：
- 聲明接口字段和返回參數，字段需要聲明是否必填、字段類型、長度以及處理規則；
- 聲明接口預估的數據量大小、調用頻率等，以保證開發時考慮到接口的健壯性；
- 聲明接口的異常處理方式，如失敗的數據是否重發、重發次數等等。
在之前的產品設計過程中，還出現過配合系統雙方的產品經理為了誰應該來寫接口文檔而爭執過。後來定了一套標準，個人認為是比較合理的，供大家參考：
原則1：一般是由數據的需求方來編寫接口需求文檔。
原則2：如果該接口是一個分發接口，則由數據的提供方來編寫接口需求文檔。
總結：
好了，說到這裡，已經把我個人這些年工作中所接觸到的API接口簡單介紹了一下。由於本人一直是做後端產品經理，因此對於前端的接口涉獵不多，不瞭解差異有多大，以上內容僅供後端產品經理參考，也希望大家能夠對文中的一些錯誤及時指正。
另外，作為一名大數據的產品經理，大數據如何利用接口對外提供服務？後續總結出自己的一套方法論後再分享。
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
