產品經理,你要懂點API接口知識!
產品經理不需要深入地去了解各個接口的實現原理,畢竟術業有專攻,但是了解什么場景應該使用什么樣的接口還是很有必要的,可以方便更好地對外提供數據服務。
剛成為產品經理的時候常常聽到開發吐槽:“這產品經理啥都不懂,這個需求那么多接口,開發都夠嗆還要聯調,居然就排這么點開發時間,出了什么問題我可不負責!”
每次聽到這樣的吐槽總會一臉懵逼——什么接口?什么聯調?我又做錯了什么?
后來自己做過開發之后,開始了解到:在系統層面上,除了看得到的頁面功能,還有很多隱藏在頁面功能之下的接口。
這篇文章就簡單總結一下:我眼中的接口是什么樣的?以及,為何要學習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接口簡單介紹了一下。由于本人一直是做后端產品經理,因此對于前端的接口涉獵不多,不了解差異有多大,以上內容僅供后端產品經理參考,也希望大家能夠對文中的一些錯誤及時指正。
另外,作為一名大數據的產品經理,大數據如何利用接口對外提供服務?后續總結出自己的一套方法論后再分享。
本文由 @LinKiD 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
寫的很好
寫的很好
感謝!
點贊
非常感謝,入職來沒專門的帶教做培訓,整天聽同事和開發對接都難理解,百度也不好查,謝謝這么通俗易懂的文章。
感謝感謝!
寫的很好
那么運營該如何寫接口文檔呢?我們這里沒產品經理,只有開發和運營。
例子簡單易懂~
感謝你的分享
感謝分享~
接口文檔讓產品經理寫有單難為人了 只有開發出身的產品經理能寫這個 這也就是為啥大廠只招開發專業的同學做產品經理了 非開發出身的產品經理也不用氣餒 只要思路清晰的表達 大多數開發人員還是能接受自己寫接口文檔的
接口文檔也是產品經理寫的呀… ? 我們都是開發自己弄。。。
先贊為敬。其實建議產品經理可以先看看接口文檔,結合你你想實現的功能,聯系到哪個地方需要那些字段數據,就能很好的理解接口所代表的含義。其實就是數據傳輸的通道,不過該通道有著自傳輸方式,格式,以及接受方式。
不是先設計需求文檔,看看需要哪些字段,大概了解各字段的數據從哪個庫拿,然后原型文檔出來了,后端才設計接口的嗎?一開始哪來的接口文檔?
參考其他項目或者產品的需求文檔學習先,這樣子和開發溝通起來會更好些
參考其他項目或者產品的“技術文檔”學習先,這樣子和開發溝通起來會更好些
很有道理。多看幾個別人寫的接口文檔之后就能很好地理解接口的應用場景和含義。
那就趕緊好好學習!
嗨LinKiD,你的文章真是通俗易懂,請問可以轉載到Great-PM公眾號上嗎?一定署名原作者的
可以的
產品經理一定要懂技術嗎
不是。看具體的工作,如果是后端系統和數據平臺的產品經理都建議懂點技術。知道如何應用各種技術即可,不需要知道技術細節。
當然,不知道技術也不妨礙做產品經理,但有些項目就沒有機會參與了。
加微信交流下
柜臺比喻挺好的,請問Api和SDK有什么區別呢
個人理解:如果說API是獲取數據的管道,那SDK就是可以實現某些功能的應用包,可以理解為你家安裝的濾水器,提供過濾服務。你安裝管道是為了獲得特定用途的水,你可以定制管道的大小,水龍頭的規格。但是濾水器是標準的產品,你只管安裝上用來濾水。
目前為止我覺得產品經理是不需要了解SDK的。
如果涉及做游戲SDK或者接入廣告SDK,還是需要一定的理解吧。個人拙見
認真看完了,。,,然而我還是沒懂啊。。。
看來用銀行做比喻還是太抽象了,哈哈。以前是大家都喜歡把接口比喻為“管道”,而你的負責系統就是一個自來水廠。如果哪一戶人家(數據的需求方,另一個系統)需要自來水,開發就鋪設一條管道通到這一戶人家,而聯調的過程就像是管道鋪設完了,要開個水龍頭試一下,水是不是真的過來了。
不能再形象了。。哈哈哈哈贊??
我一直都不太清楚接口是個啥,每次問他們就說是調用什么數據~ 哎 笨死了
你有插銷。他們給你個插座。你就能拿到你想要的電。
還是這樣形容我就清楚了 ??
一開始也有這種感覺…就好像你問他筷子是什么,他就告訴你這是吃飯的家伙,然后你還以為是個碗 ?
太扎心了哈哈哈,我是個假的產品
我覺得接口不管怎么比喻,都還是一個很情色的東西。
你車速太快了老司機
哈哈
??
接口無非是干4個事情,對數據(數據庫)增、刪、改、查,接口另一端(后端)就是后端程序員寫好的sql和邏輯判斷,前端調用接口就是間接的調用sql操作數據庫。如果有錯誤,請指出,謝謝!
和大家討論一波感覺確實明白了不少~
調用接口就是獲取目標數據,調用的接口會給你返回請求的參數值
好~謝謝講解噢