剛入門產(chǎn)品經(jīng)理的時候，對接口（API）一片空白，不理解接口（API）是什么？更別說能看懂接口文檔了，在接口上踩了很多坑。

　　比如這些場景：

　　場景1：開需求會，提了新的需求，開發(fā)說，你這個需求太復雜，光接口就有20幾個，根本做不完。我一聽就蒙了，雖然表示懷疑，卻無力反駁。

　　場景2：好不容易理好接口，提了新的需求，，開發(fā)說，你把讀寫接口搞混了，不可能一個接口實現(xiàn)所有功能。

　　場景3：其他部門向我提了兩個接口需求，我找到開發(fā)完成接口后交付給需求方，結果需求方說接口的響應時間和并發(fā)數(shù)達不到要求，得推倒重做，oh my god！

　　究竟接口是什么呢？又如何看懂接口文檔？接口性能對功能的影響是什么呢？如何在產(chǎn)品需求中理清接口呢？這篇文章將解答你的疑惑。

一、API是什么？

API是應用程序編程接口，如何理解呢？

API就好像是一個傳輸數(shù)據(jù)的通道，入口需要請求數(shù)據(jù)，就好像是通關密碼，而出口需要返回結果。

　　接口的使用方不需要關心接口是如何實現(xiàn)的，他只關心能不能拿到接口最后的返回結果。

　　接口的提供方需要定義接口請求參數(shù)、響應內(nèi)容等，還需要關注接口的性能，是否能滿足高并發(fā)的調(diào)用，接口的穩(wěn)定性如何……

二、如何看懂接口文檔

　　以一個真實的接口文檔做范例，給大家講解：

接口一般分為以下幾個部分：

1、接口描述

　　簡單描述接口的邏輯和作用

2、接口地址

　　接口的正式url和接口測試的url，需求方通過調(diào)用接口url，獲取響應內(nèi)容

3、請求方法

　　一般來說，接口最常見的請求方法為GET和POST兩種方式，即讀接口和寫接口。通過這兩種方式，實現(xiàn)對數(shù)據(jù)的增刪查改。刪查改本質(zhì)都是寫的動作。

4、請求參數(shù)

　　即需要請求的字段名的名稱和規(guī)則：

 都是哪些字段，字段的類型是什么，是否必填字段等等

5、響應內(nèi)容

　　接口返回的字段名稱和規(guī)則

注意：大部分開發(fā)往往不會把所有的字段羅列，只會列出比較重要的字段。

　　當你發(fā)現(xiàn)，接口文檔中沒有你需求的字段，別著急找開發(fā)，可以看下實例中，有沒有需求的字段。

　　比如這個文檔，你可以很明顯的發(fā)現(xiàn)，響應內(nèi)容中缺少了數(shù)據(jù)寫入狀態(tài)這個字段，但是在后續(xù)實例中，是包含has sucess這個字段的。

6、錯誤代碼

　　對接口的錯誤用代碼進行歸類，以便能快速找到錯誤原因，解決問題。

7、實例

　　實際調(diào)用時的響應的內(nèi)容。

三、接口性能

　　不同的業(yè)務場景對于接口性能的要求是各不相同的，所以在做接口之前，一定要開發(fā)討論，正在做的接口是否能滿足調(diào)用的需求，未來是否會增加新的調(diào)用方，擴展性如何？不然就會出現(xiàn)，前文中場景3的悲劇。

　　接口如何優(yōu)化，pm可以不用了解，由開發(fā)去把關，但我們需要知道接口性能的核心指標。

1、接口響應時間、并發(fā)數(shù)

接口響應時間：

　　從請求端發(fā)送一個請求開始，到接收到響應結果所經(jīng)歷的時間。

并發(fā)數(shù)：

　　指同時訪問服務器站點的連接數(shù)。

　　可以進行簡單估算，如果響應時間<200ms，1s=1000ms，1000 200="5，如果有10個線程，秒并發(fā)">50，一分鐘就可以連接超過50*60=3000次，一個小時就可以連接超過3000*60=180000次

　　如果有20個線程，那秒并發(fā)可以超過100。

　　實際的并發(fā)數(shù)并不總是符合我們的期望，需要壓測或者實際使用才能知道接口能支持的最大并發(fā)數(shù)是多少。

　　響應時間越短，多線程并發(fā)數(shù)越高，接口性能越好。

　　不是所有的業(yè)務場景都需要“最好”的性能，滿足業(yè)務場景即可。

2、線程

　　一個程序有多個進程，一個進程有多個線程。

　　如果把上課的過程比作進程，那么每個學生就是一個線程，CPU是老師，教室是內(nèi)存，他們共享教室，即線程共享進程的內(nèi)存空間。每一個時刻，只能一個學生問老師（CPU）問題，老師回答完畢，接著回答下一個學生問題。

三、如何在產(chǎn)品需求中理清接口

1、如何拆解接口

　　大家牢記一句話，接口分讀接口和寫接口。

　　不管多復雜的需求，涉及到多少個接口，其本質(zhì)就是讀接口和寫接口。

　　舉幾個例子：

1. 游戲點券充值接口

2. 獲取用戶列表接口

3. 評論標記精選接口

4. 投放卡券接口

　　其中，1、3、4都是寫接口，請求方式為POST，因為都涉及到寫入相關數(shù)據(jù)的動作。2是讀接口，請求方式為GET，涉及讀取和查詢數(shù)據(jù)。

　　這樣來看，接口貌似很好理解，有寫入數(shù)據(jù)的就是寫接口，有讀取數(shù)據(jù)就是讀接口

　　但是在理產(chǎn)品需求時，產(chǎn)品小白常常理不清楚功能對應的接口，解決辦法很簡單，就是拆解需求。

　　比如我們要設計一個身份證實名認證的功能，需要滿足一個身份信息只能實名認證一個賬號，如果用戶認證了數(shù)據(jù)庫里已經(jīng)存在的身份證，那么會提醒用戶身份信息被占用。

　　首先，我們需要拆解需求：

1. 實名認證是針對未實名的用戶，已實名過的用戶無需再進行實名，所以我們需要一個查詢接口

2. 還需要一個寫接口，讓用戶去寫入身份信息或修改身份信息

3. 因為一對一的要求，所以還需要一個查詢數(shù)據(jù)庫是否存在已有的身份信息

4. 某些用戶實名后，可能會因為各種理由，想解除實名，所以還需要一個刪除的接口

　　其次我們需要明確接口傳輸?shù)淖侄?/span>

2、接口的請求和響應字段

（1）接口需要請求哪些字段，是否必填，字段的格式有什么要求嗎？

　　比如上面提到的（3）查詢數(shù)據(jù)庫是否存在已有的身份信息，請求字段為會員ID，姓名，身份證號，均為必填字段，姓名首先必須得純中文，身份證號也必須滿足位數(shù)要求。

（2）接口需要返回哪些字段，是否必填，字段的格式有什么要求嗎？

　　原理同上

3、最后啰嗦一些注意事項

　　除了功能和邏輯外，還需要注意接口的異常和錯誤情況，

　?。?/span>1）前端做好交互，提示用戶，以免因為接口不穩(wěn)定，導致線上bug，而前端缺乏引導，導致用戶不能正常操作，對產(chǎn)品頗多怨言。

　?。?/span>2）對于某些重要的功能，還要做好兩手準備，準備兩個接口，一個接口掛掉還可以用另外一個接口。

 

來源：人人都是產(chǎn)品經(jīng)理