借助生活中熟悉的事物來理解接口,從插座到接口,你對接口的理解是不是更形象生動了?
産品經理在日常的工作中,會經常與技術溝通。
例如,在需求評審會上,開發說,你這個需求太複雜,光接口就十幾個;又比如技術說聯調接口,接口的響應時間等——這些都關于接口,如果産品經理不懂接口,顯然就不能跟技術愉快地溝通了。
這篇文章就來講解“接口”這個玩意兒。
一、生活中的“接口”先來看看接口的定義:
API(Application Programming Interface,應用程序編程接口)是一些預先定義的函數,包括接口地址、傳入參數和返回參數,目的是實現系統之間的相互通信。
嗯,太複雜,太抽象了。
認知心理學上講,學習新事物有個技巧:将陌生的事物與大腦中熟悉的事物相聯系,這樣便于理解新的事物。
那生活中有沒有類似的概念呢?
在日常生活中,兩個實物之間進行連接的部分成為接口。
沒錯,插座就是一個接口!!!
手機的插座、風扇的插座、台燈的插座,都是統一标準的二插,隻要找到插座,就可以充電!
所有的電器隻要符合接口規範,便可以通過接口獲得電(相應地,所有系統隻要符合另一個系統的接口規範,便可以通過接口獲取數據)。
舉一個具體的例子:
小明的手機沒電了,需要充電,怎麼辦?
小明需要找到電源插座,然後通過充電器與手機相連進行充電。如下圖所示:
二、技術說的“接口”
而技術所說的接口可以理解為:基于需求為了獲得某些數據,正常狀态下傳入請求參數,會收到該數據範圍内的返回參數。
再來看一個産品中的例子,釘釘開放平台所提供的獲取員工花名冊字段信息的接口(如下圖所示):
接下來,本文将從接口的四大組成“接口地址、請求方法、請求參數、返回内容和系統”來講解接口。
1. 請求方式:get/post
如果把互聯網比喻為信息高速公路,那麼既然是高速公路,就得有交通規則對不對?不然你開拖拉機的、和開大卡車的都在一條路上飙車,很容易堵車是不是?
因此信息高速公路的交通規則中,就有一條特别規定了,開拖拉機的和開卡車分别應該走什麼車道。
開拖拉機的運載的貨物相對比較少,也很容易看出來運載的是什麼貨物,因此建議走get車道,雖然路窄一點,但好在過關卡的時候不用下車檢查。
大卡車運載的貨物比較多還比較隐蔽,因此走post車道。
圖1是一個get請求,他的參數是拼接在url(query string)裡的。
圖2是一個post請求,它的參數是在request body(請求體)中的,以鍵值對的形式傳遞參數。
2. 請求地址
顧名思義就是接口的地址,以網址的形式展現,你通過發送請求給這個網址來對接口進行交互操作。
3. 參數說明
即傳輸參數的時候要帶的一些參數,一般文檔中會用表格的形式清晰的說明。
當我向接口發送攜帶請求參數的請求時,都要攜帶什麼字段,規則是什麼。如下圖:
4. 返回内容
返回内容一般會以JSON或是XML的形式返回。
XML和JSON是兩種完全不同的數據表達方式,他們分别采用完全不同的格式将原始數據轉換成XML或者JOSN格式數據,再借用貨車與高速公路的例子,XML或JSON是車裝載的貨物。
像上面貼出來的這種接口,還是比較好閱讀的。
如果我們發送userid_list和field_filter_list,就是員工userid列表和花名冊字段列表,接口就返回給我們errcode返回碼以及errmsg返回碼的文本描述,提示我們是否返回成功。
假若成功,便會返回如下的花名冊字段信息:
三、接口的性能
1. 接口響應時間
從請求端發送一個請求開始,到接收到響應結果所經曆的時間。
2. 并發數
指同時訪問服務器站點的連接數。
可以進行簡單估算,如果響應時間<200ms,1s=1000ms,1000/200=5,那麼1個線程,秒并發>5,如果有20個線程,那秒并發可以超過100。
響應時間越短,多線程并發數越高,接口性能越好。不是所有的業務場景都需要“最好”的性能,滿足業務場景即可。
3. 進程和線程
一個程序有多個進程,一個進程有多個線程。
對于操作系統來說,一個任務就是一個進程。比如,打開一個浏覽器就是啟動一個浏覽器進程,打開一個記事本就啟動了一個記事本進程,打開兩個記事本就啟動了兩個記事本進程,打開一個Word就啟動了一個Word進程。
有些進程還不止同時幹一件事,比如Word,它可以同時進行打字、拼寫檢查、打印等事情。
在一個進程内部,要同時幹多件事,就需要同時運行多個“子任務”,我們把進程内的這些“子任務”稱為線程。
四、小結可以發現,理解好接口,可以幫助産品經理:
- 更加理解各個系統之間的數據是如何流轉的,在需求設計階段考慮會更加全面、嚴謹。
- 雖然不懂如何實現,但能大概估摸出開發總體工作量,在安排項目計劃時會考慮到接口的難易程度。
最後用一句話總結一下:
數據與用戶行為相聯系,接口實現系統之間的數據交互,從功能的角度講,便是功能決定接口,接口反作用于功能。
本文由 @澤 原創發布于人人都是産品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!