藉助生活中熟悉的事物來理解接口，從插座到接口，你對接口的理解是不是更形象生動了？
產品經理在日常的工作中，會經常與技術溝通。
例如，在需求評審會上，開發說，你這個需求太複雜，光接口就十幾個；又比如技術說聯調接口，接口的響應時間等——這些都關於接口，如果產品經理不懂接口，顯然就不能跟技術愉快地溝通了。
這篇文章就來講解“接口”這個玩意兒。
一、生活中的“接口”
先來看看接口的定義：
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協議
閱讀更多 人人都是產品經理 的文章
