剛接觸產(chǎn)品工作時(shí)，對(duì)接口（API）一片空白，不理解接口（API）是什么？更別說能看懂接口文檔了，在接口上踩了很多坑。接下來，將結(jié)合自己的親身經(jīng)驗(yàn)與大家分享。

剛接觸產(chǎn)品工作時(shí)，對(duì)接口（API）一片空白，不理解接口（API）是什么？更別說能看懂接口文檔了，在接口上踩了很多坑。

比如這些場(chǎng)景：

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

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

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

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

一、API是什么？

API是應(yīng)用程序編程接口，如何理解呢？

API就好像是一個(gè)傳輸數(shù)據(jù)的通道，入口需要請(qǐng)求數(shù)據(jù)，就好像是通關(guān)密碼，而出口需要返回結(jié)果。

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

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

二、如何看懂接口文檔

以一個(gè)真實(shí)的接口文檔做范例，給大家講解：

接口一般分為以下幾個(gè)部分：

1、接口描述

簡(jiǎn)單描述接口的邏輯和作用

2、接口地址

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

3、請(qǐng)求方法

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

4、請(qǐng)求參數(shù)

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

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

5、響應(yīng)內(nèi)容

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

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

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

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

6、錯(cuò)誤代碼

對(duì)接口的錯(cuò)誤用代碼進(jìn)行歸類，以便能快速找到錯(cuò)誤原因，解決問題。

7、實(shí)例

實(shí)際調(diào)用時(shí)的響應(yīng)的內(nèi)容。

三、接口性能

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

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

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

接口響應(yīng)時(shí)間：

從請(qǐng)求端發(fā)送一個(gè)請(qǐng)求開始，到接收到響應(yīng)結(jié)果所經(jīng)歷的時(shí)間。

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

指同時(shí)訪問服務(wù)器站點(diǎn)的連接數(shù)。

可以進(jìn)行簡(jiǎn)單估算，如果響應(yīng)時(shí)間<200ms，1s=1000ms，1000/200=5，如果有10個(gè)線程，秒并發(fā)>50，一分鐘就可以連接超過50*60=3000次，一個(gè)小時(shí)就可以連接超過3000*60=180000次

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

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

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

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

2、線程

一個(gè)程序有多個(gè)進(jìn)程，一個(gè)進(jìn)程有多個(gè)線程。

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

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

1、如何拆解接口

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

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

舉幾個(gè)例子：

1. 游戲點(diǎn)券充值接口
2. 獲取用戶列表接口
3. 評(píng)論標(biāo)記精選接口
4. 投放卡券接口

其中，1、3、4都是寫接口，請(qǐng)求方式為POST，因?yàn)槎忌婕暗綄懭胂嚓P(guān)數(shù)據(jù)的動(dòng)作。2是讀接口，請(qǐng)求方式為GET，涉及讀取和查詢數(shù)據(jù)。

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

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

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

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

1. 實(shí)名認(rèn)證是針對(duì)未實(shí)名的用戶，已實(shí)名過的用戶無需再進(jìn)行實(shí)名，所以我們需要一個(gè)查詢接口
2. 還需要一個(gè)寫接口，讓用戶去寫入身份信息或修改身份信息
3. 因?yàn)橐粚?duì)一的要求，所以還需要一個(gè)查詢數(shù)據(jù)庫是否存在已有的身份信息
4. 某些用戶實(shí)名后，可能會(huì)因?yàn)楦鞣N理由，想解除實(shí)名，所以還需要一個(gè)刪除的接口

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

2、接口的請(qǐng)求和響應(yīng)字段

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

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

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

原理同上

3、最后啰嗦一些注意事項(xiàng)

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

（1）前端做好交互，提示用戶，以免因?yàn)榻涌诓环€(wěn)定，導(dǎo)致線上bug，而前端缺乏引導(dǎo)，導(dǎo)致用戶不能正常操作，對(duì)產(chǎn)品頗多怨言。

（2）對(duì)于某些重要的功能，還要做好兩手準(zhǔn)備，準(zhǔn)備兩個(gè)接口，一個(gè)接口掛掉還可以用另外一個(gè)接口。

本文由 @丹小喵?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。