起點(diǎn)課堂會(huì)員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會(huì)特權(quán)
個(gè)人IP打造特權(quán)
30+門(mén)專(zhuān)項(xiàng)技能課
1300+專(zhuān)題課程
12場(chǎng)職場(chǎng)軟技能直播
12場(chǎng)求職輔導(dǎo)直播
12場(chǎng)專(zhuān)業(yè)技能直播
會(huì)員專(zhuān)屬社群
榮耀標(biāo)識(shí)產(chǎn)品經(jīng)理如何繞開(kāi)API的坑
剛接觸產(chǎn)品工作時(shí)，對(duì)接口（API）一片空白，不理解接口（API）是什么？更別說(shuō)能看懂接口文檔了，在接口上踩了很多坑。接下來(lái)，將結(jié)合自己的親身經(jīng)驗(yàn)與大家分享。
剛接觸產(chǎn)品工作時(shí)，對(duì)接口（API）一片空白，不理解接口（API）是什么？更別說(shuō)能看懂接口文檔了，在接口上踩了很多坑。
比如這些場(chǎng)景：
場(chǎng)景1：開(kāi)需求會(huì)，提了新的需求，開(kāi)發(fā)說(shuō)，你這個(gè)需求太復(fù)雜，光接口就有20幾個(gè)，根本做不完。我一聽(tīng)就蒙了，雖然表示懷疑，卻無(wú)力反駁。
場(chǎng)景2：好不容易理好接口，提了新的需求，，開(kāi)發(fā)說(shuō)，你把讀寫(xiě)接口搞混了，不可能一個(gè)接口實(shí)現(xiàn)所有功能。
場(chǎng)景3：其他部門(mén)向我提了兩個(gè)接口需求，我找到開(kāi)發(fā)完成接口后交付給需求方，結(jié)果需求方說(shuō)接口的響應(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)注接口的性能，是否能滿(mǎn)足高并發(fā)的調(diào)用，接口的穩(wěn)定性如何……
二、如何看懂接口文檔
以一個(gè)真實(shí)的接口文檔做范例，給大家講解：
接口一般分為以下幾個(gè)部分：
1、接口描述
簡(jiǎn)單描述接口的邏輯和作用
2、接口地址
接口的正式url和接口測(cè)試的url，需求方通過(guò)調(diào)用接口url，獲取響應(yīng)內(nèi)容
3、請(qǐng)求方法
一般來(lái)說(shuō)，接口最常見(jiàn)的請(qǐng)求方法為GET和POST兩種方式，即讀接口和寫(xiě)接口。通過(guò)這兩種方式，實(shí)現(xiàn)對(duì)數(shù)據(jù)的增刪查改。增刪改本質(zhì)都是寫(xiě)的動(dòng)作。
4、請(qǐng)求參數(shù)
即需要請(qǐng)求的字段名的名稱(chēng)和規(guī)則：
都是哪些字段，字段的類(lèi)型是什么，是否必填字段等等
5、響應(yīng)內(nèi)容
接口返回的字段名稱(chēng)和規(guī)則
注意：大部分開(kāi)發(fā)往往不會(huì)把所有的字段羅列，只會(huì)列出比較重要的字段。
當(dāng)你發(fā)現(xiàn)，接口文檔中沒(méi)有你需求的字段，別著急找開(kāi)發(fā)，可以看下實(shí)例中，有沒(méi)有需求的字段。
比如這個(gè)文檔，你可以很明顯的發(fā)現(xiàn)，響應(yīng)內(nèi)容中缺少了數(shù)據(jù)寫(xiě)入狀態(tài)這個(gè)字段，但是在后續(xù)實(shí)例中，是包含has sucess這個(gè)字段的。
6、錯(cuò)誤代碼
對(duì)接口的錯(cuò)誤用代碼進(jìn)行歸類(lèi)，以便能快速找到錯(cuò)誤原因，解決問(wèn)題。
7、實(shí)例
實(shí)際調(diào)用時(shí)的響應(yīng)的內(nèi)容。
三、接口性能
不同的業(yè)務(wù)場(chǎng)景對(duì)于接口性能的要求是各不相同的，所以在做接口之前，一定要開(kāi)發(fā)討論，正在做的接口是否能滿(mǎn)足調(diào)用的需求，未來(lái)是否會(huì)增加新的調(diào)用方，擴(kuò)展性如何？不然就會(huì)出現(xiàn)，前文中場(chǎng)景3的悲劇。
接口如何優(yōu)化，pm可以不用了解，由開(kāi)發(fā)去把關(guān)，但我們需要知道接口性能的核心指標(biāo)。
1、接口響應(yīng)時(shí)間、并發(fā)數(shù)
接口響應(yīng)時(shí)間：
從請(qǐng)求端發(fā)送一個(gè)請(qǐng)求開(kāi)始，到接收到響應(yīng)結(jié)果所經(jīng)歷的時(shí)間。
并發(fā)數(shù)：
指同時(shí)訪問(wèn)服務(wù)器站點(diǎn)的連接數(shù)。
可以進(jìn)行簡(jiǎn)單估算，如果響應(yīng)時(shí)間<200ms，1s=1000ms，1000/200=5，如果有10個(gè)線程，秒并發(fā)>50，一分鐘就可以連接超過(guò)50*60=3000次，一個(gè)小時(shí)就可以連接超過(guò)3000*60=180000次
如果有20個(gè)線程，那秒并發(fā)可以超過(guò)100。
實(shí)際的并發(fā)數(shù)并不總是符合我們的期望，需要壓測(cè)或者實(shí)際使用才能知道接口能支持的最大并發(fā)數(shù)是多少。
響應(yīng)時(shí)間越短，多線程并發(fā)數(shù)越高，接口性能越好。
不是所有的業(yè)務(wù)場(chǎng)景都需要“最好”的性能，滿(mǎn)足業(yè)務(wù)場(chǎng)景即可。
2、線程
一個(gè)程序有多個(gè)進(jìn)程，一個(gè)進(jìn)程有多個(gè)線程。
如果把上課的過(guò)程比作進(jìn)程，那么每個(gè)學(xué)生就是一個(gè)線程，CPU是老師，教室是內(nèi)存，他們共享教室，即線程共享進(jìn)程的內(nèi)存空間。每一個(gè)時(shí)刻，只能一個(gè)學(xué)生問(wèn)老師（CPU）問(wèn)題，老師回答完畢，接著回答下一個(gè)學(xué)生問(wèn)題。
三、如何在產(chǎn)品需求中理清接口
1、如何拆解接口
大家牢記一句話，接口分讀接口和寫(xiě)接口。
不管多復(fù)雜的需求，涉及到多少個(gè)接口，其本質(zhì)就是讀接口和寫(xiě)接口。
舉幾個(gè)例子：
- 游戲點(diǎn)券充值接口
- 獲取用戶(hù)列表接口
- 評(píng)論標(biāo)記精選接口
- 投放卡券接口
其中，1、3、4都是寫(xiě)接口，請(qǐng)求方式為POST，因?yàn)槎忌婕暗綄?xiě)入相關(guān)數(shù)據(jù)的動(dòng)作。2是讀接口，請(qǐng)求方式為GET，涉及讀取和查詢(xún)數(shù)據(jù)。
這樣來(lái)看，接口貌似很好理解，有寫(xiě)入數(shù)據(jù)的就是寫(xiě)接口，有讀取數(shù)據(jù)就是讀接口
但是在理產(chǎn)品需求時(shí)，產(chǎn)品小白常常理不清楚功能對(duì)應(yīng)的接口，解決辦法很簡(jiǎn)單，就是拆解需求。
比如我們要設(shè)計(jì)一個(gè)身份證實(shí)名認(rèn)證的功能，需要滿(mǎn)足一個(gè)身份信息只能實(shí)名認(rèn)證一個(gè)賬號(hào)，如果用戶(hù)認(rèn)證了數(shù)據(jù)庫(kù)里已經(jīng)存在的身份證，那么會(huì)提醒用戶(hù)身份信息被占用。
首先，我們需要拆解需求：
- 實(shí)名認(rèn)證是針對(duì)未實(shí)名的用戶(hù)，已實(shí)名過(guò)的用戶(hù)無(wú)需再進(jìn)行實(shí)名，所以我們需要一個(gè)查詢(xún)接口
- 還需要一個(gè)寫(xiě)接口，讓用戶(hù)去寫(xiě)入身份信息或修改身份信息
- 因?yàn)橐粚?duì)一的要求，所以還需要一個(gè)查詢(xún)數(shù)據(jù)庫(kù)是否存在已有的身份信息
- 某些用戶(hù)實(shí)名后，可能會(huì)因?yàn)楦鞣N理由，想解除實(shí)名，所以還需要一個(gè)刪除的接口
其次我們需要明確接口傳輸?shù)淖侄?/p>
2、接口的請(qǐng)求和響應(yīng)字段
（1）接口需要請(qǐng)求哪些字段，是否必填，字段的格式有什么要求嗎？
比如上面提到的（3）查詢(xún)數(shù)據(jù)庫(kù)是否存在已有的身份信息，請(qǐng)求字段為會(huì)員ID，姓名，身份證號(hào)，均為必填字段，姓名首先必須得純中文，身份證號(hào)也必須滿(mǎn)足位數(shù)要求。
（2）接口需要返回哪些字段，是否必填，字段的格式有什么要求嗎？
原理同上
3、最后啰嗦一些注意事項(xiàng)
除了功能和邏輯外，還需要注意接口的異常和錯(cuò)誤情況，
（1）前端做好交互，提示用戶(hù)，以免因?yàn)榻涌诓环€(wěn)定，導(dǎo)致線上bug，而前端缺乏引導(dǎo)，導(dǎo)致用戶(hù)不能正常操作，對(duì)產(chǎn)品頗多怨言。
（2）對(duì)于某些重要的功能，還要做好兩手準(zhǔn)備，準(zhǔn)備兩個(gè)接口，一個(gè)接口掛掉還可以用另外一個(gè)接口。
本文由 @丹小喵?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。
感謝樓主，硬核干貨。。。。好的東西，多久都有用。。感恩講解。
初級(jí)產(chǎn)品，一直不太懂接口，之前只聽(tīng)說(shuō)能看懂接口文檔就行，涉及第三方接口可能要考慮下調(diào)用哪些信息，這個(gè)系統(tǒng)本身需要哪些接口
還需要產(chǎn)品考慮嗎
如果不知道調(diào)用信息，那你怎么知道能不能符合你的業(yè)務(wù)場(chǎng)景？如果字段漏了和錯(cuò)了怎么辦
目前我也在弄對(duì)三方接口的事，打算采用先理清第三方可以返回哪些字段，再和運(yùn)營(yíng)確認(rèn)哪些字段，做一個(gè)匹配，再去協(xié)商后面的事
關(guān)于線程和進(jìn)程， 他們不都是過(guò)程嗎？ 所以，這個(gè)地方線程確切一點(diǎn)表示，是不是學(xué)生向老師提問(wèn)（學(xué)習(xí)）這個(gè)過(guò)程
可以簡(jiǎn)單理解能承受住多端和多用戶(hù)量訪問(wèn)，這塊接口性能測(cè)試會(huì)解決，只是幫助你能看懂性能測(cè)試報(bào)告
終于看懂一些了……剛開(kāi)始叫我研究API整個(gè)人都是懵的，連概念都搞不清楚 ??
文中提到的身份證實(shí)名認(rèn)證接口，數(shù)據(jù)智匯可以提供~
您的線程比喻很形象
昨天新產(chǎn)品上線，就出現(xiàn)了接口調(diào)用超時(shí)，調(diào)用失敗，用戶(hù)中途退出導(dǎo)致前端發(fā)送給后臺(tái)的信息失敗，一連串的問(wèn)題都是沒(méi)有考慮全接口使用異常情況如何處理。接口的性能包括響應(yīng)時(shí)間，并發(fā)量，多線程等，正是因?yàn)樵趲状紊暇€迭代使用接口上遇到這樣那樣的問(wèn)題，讓我才對(duì)接口有了點(diǎn)認(rèn)知，之前還在為接口誰(shuí)來(lái)提供，誰(shuí)調(diào)誰(shuí)，地址是用http還是https而苦惱。跟技術(shù)同事搞好關(guān)系，他們會(huì)為你一一解答；
接口就是不同程序員約定的信號(hào)交流規(guī)則，相當(dāng)于一扇特制的門(mén)，符合要求的信息會(huì)允許進(jìn)出，不符合的會(huì)拒之門(mén)外
很贊，最近我就在弄跟客戶(hù)接口對(duì)接，不懂技術(shù)迷迷糊糊的，現(xiàn)在看了后好多了
這才是真正需要的，站內(nèi)標(biāo)題黨多了，說(shuō)的一套一套的
挺好的啊，能自己主動(dòng)去學(xué)習(xí)這類(lèi)知識(shí)，對(duì)自己也是一種提升，總不至于別人說(shuō)什么的時(shí)候，跟個(gè)白癡一樣。支持你??！像你這種能主動(dòng)學(xué)習(xí)的不多了?。〖佑?！
謝謝鼓勵(lì)??
個(gè)人見(jiàn)解，專(zhuān)業(yè)的事由專(zhuān)業(yè)的人去做，你以產(chǎn)品角度所考慮的接口設(shè)計(jì)和開(kāi)發(fā)角度所考慮的接口設(shè)計(jì)，不是一致的。產(chǎn)品只需要提出功能執(zhí)行所需要的數(shù)據(jù)就行，至于字段的定義，post還是get，就別越俎代庖了。當(dāng)然，能了解接口的相關(guān)原理對(duì)產(chǎn)品來(lái)講不是壞事。
好好想想你這個(gè)需求靠譜不，就行了
我是個(gè)新人產(chǎn)品好多都不懂
我最近被騰訊智慧校園的API接口整瘋了，復(fù)雜冗長(zhǎng)而且還會(huì)時(shí)不時(shí)的不提醒更新，
根據(jù)需求分析產(chǎn)品需要哪些借口，借口的用處就行了。
多跟產(chǎn)品開(kāi)發(fā)聊聊天
最近正在被接口困擾，看到這篇文之后似乎get到了什么。。。謝謝！
產(chǎn)品需要這么詳細(xì)的看接口字段這些么~？
其實(shí)接口的字段問(wèn)題往往測(cè)試或上線的時(shí)候才爆發(fā)，影響交互。開(kāi)發(fā)也是人，也會(huì)出問(wèn)題，產(chǎn)品多注意可以減少最后的返工。
最開(kāi)始開(kāi)發(fā)也是這么坑我的，甩個(gè)接口讓我自己看他們寫(xiě)漏了什么，我當(dāng)時(shí)就日了個(gè)狗了，我自己試著看里面參數(shù)有沒(méi)有我要的，有哪些是他們沒(méi)有的，這是第一個(gè)步驟吧，到了后面底氣足了，我直接提需求就夠了，說(shuō)明需求說(shuō)明流程說(shuō)明想要什么樣子的結(jié)果，具體做的做不到我們慢慢說(shuō)，但是大部分的做不到都開(kāi)發(fā)自己在找借口
二、3、請(qǐng)求方法
一般來(lái)說(shuō)，接口最常見(jiàn)的請(qǐng)求方法為GET和POST兩種方式，即讀接口和寫(xiě)接口。通過(guò)這兩種方式，實(shí)現(xiàn)對(duì)數(shù)據(jù)的增刪查改。刪查改本質(zhì)都是寫(xiě)的動(dòng)作。
（這個(gè)位置最后一句錯(cuò)了，應(yīng)該增刪改是寫(xiě)吧）
恩恩，筆誤，謝謝提醒
初步驗(yàn)證該產(chǎn)品經(jīng)理要么是初入行，要么是開(kāi)發(fā)轉(zhuǎn)的產(chǎn)品經(jīng)理，并且進(jìn)過(guò)接口的坑，哈哈哈，開(kāi)個(gè)小玩笑哈。
如果是開(kāi)發(fā)轉(zhuǎn)的產(chǎn)品怎么會(huì)不知道接口的東西呢
我的意思是當(dāng)他做開(kāi)發(fā)的時(shí)候，讓不懂接口的產(chǎn)品經(jīng)理困擾過(guò)。
接口也要產(chǎn)品經(jīng)理去做 那程序的都干啥去
感謝分享~不過(guò)在寫(xiě)PRD時(shí)需要寫(xiě)的這么清楚嗎？還要區(qū)分post和get？我們現(xiàn)在只提我想要什么樣的需求，不提前后端具體的實(shí)現(xiàn)方式！ ??
接口文檔是程序員寫(xiě)的，PRD里要寫(xiě)的是產(chǎn)品需求中涉及哪些接口，接口能實(shí)現(xiàn)的功能是什么。了解這些的原因：首先，接口的字段是需要產(chǎn)品去明確的，字段沒(méi)溝通清楚，就會(huì)返工。其次，開(kāi)發(fā)提供的接口文檔產(chǎn)品是有責(zé)任檢查的，請(qǐng)求值和返回值都要看好，如果是本部門(mén)的協(xié)作還好，漏了什么補(bǔ)什么，錯(cuò)了什么改什么，如果跨部門(mén)，一不注意都是坑