還記得5月，人生第一個產品經理面試，面試官問你知道api嗎，當時腦袋一懵。事后，決定一定要把它弄清楚。在查詢資料后發現，API確實對于產品經理來說那是相當重要：1.對技術理解更深刻，結合已有新的接口，讓產品有更豐富的可行性，并降低工作量。2.更好地預估開發工作量，制定合適產品方案
文章將從API介紹，分類，API文檔內容和案例四個方面進行介紹。
1.API是什么
全名：Application Programming Interface? ? ?中文名：應用程序編程接口
百度百科釋義：API是一些預先定義的函數，目的是提供應用程序與開發人員基于某軟件或硬件得以訪問一組例程的能力，而又無需訪問源碼，或理解內部工作機制的細節。
看到這你是不是和我一樣有點懵,這也太抽象了。于是我又找了一些相關文章和他人的探討。
最后找到一個比較清晰易懂的解釋：
“簡單的說，開放接口是一個抽象的概念，直接聽名字就知道他是為了連接而開放的入口，以讓別人的程序能夠調用你的程序數據。就像你的電腦、手機有一些USB接口，也可以說是開放了接口，有了這些接口別人就可以用他來做插U盤或充電等功能。只是說API不是硬件接口，而是程序軟件接口罷了。”
舉個例子，蓄水池與水泵。
如果把提供接口的一方，比作蓄水池，那么池子里裝的就是一些封裝好的數據啊函數之類之類。這時候如果蓄水池想把他的水，分享給其他人，他就需要在自己身上造個出水口，這個出水口就是所謂的接口。
2.API的種類
a.根據響應的機制可以分為同步、異步接口：
同步接口：A系統請求B系統接口之后，必須獲得B系統接口的響應后才會執行下一步操作。
例如：登錄操作的時候調用第三方平臺接口（如微信）進行登錄，需要跳轉到微信進行驗證并返回驗證結果后，才能登錄成功。
異步接口：A系統請求B系統接口之后，不需要等待源系統返回結果就可以進行下一步操作。
例如：在滴滴打車之后，司機點擊結束行程后，不需要等待銀行付款成功之后再開始下一個訂單。因為此時滴滴已經驗證過司機、乘客的銀行賬戶或者支付寶賬戶，確認了雙方交易的合法性就可以結束訂單。
這時，我們看到的是我們已經付款成功（其實銀行可能還沒扣款），而滴滴后臺會將這筆交易流水傳給銀行，在銀行驗證后再進行扣款、付款操作。
b.根據接口的觸發形式可以分為分發、訂閱接口
分發接口：A系統產生新數據的時候就分發給B系統（也可以是多個）。
例如：電商網站后臺的客戶管理系統，在產生了一個新的黑名單客戶的時候，就會將數據分發到訂單、推薦等等各個系統，以便及時攔截這部分客戶的訂單。
訂閱接口：B系統在需要的時候調用A系統的接口進行數據訂閱。
例如：用戶在股票交易軟件中查詢銀行賬戶余額的時候才會調用銀行的余額查詢接口，而股票交易軟件自身不存儲這個數據。
3.接口文檔內容
如何調用接口，需要通過接口文檔進行說明。其主要內容有以下幾點：
接口描述：這個接口是用來干嘛的，以及相關的規則；
接口地址：以網址的形式展現，你通過發送請求給這個網址來對接口進行交互操作；
請求方法：常用的有post（寫接口）和get（讀接口）兩種方式，讀接口即查詢相關數據，寫包括修改，增加或刪減數據。（請求指令可以用很多種語言來寫，一般有curl、php、python、java等等）
注：我們通常說的http傳輸形式最基本的方法有4種，分別是GET，POST，PUT，DELETE。我們可以這樣認為：一個URL地址，它用于描述一個網絡上的資源，而HTTP中的GET，POST，PUT，DELETE就對應著對這個資源的查，改，增，刪4個操作。GET一般用于獲取/查詢資源信息，而POST一般用于更新資源信息。不過對資源的增，刪，改，查操作，其實都可以通過GET/POST完成，不需要用到PUT和DELETE。
請求參數：請求該接口時，需要提供的參數，參數屬性包括名稱、類型、是否必填、描述等；
返回參數：接口正常響應后，返回的內容；
錯誤代碼：接口請求失敗后，返回的錯誤代碼。
4.api案例展示
這里采用的是@PMnote前輩最初所負責的加油卡虛擬充值服務，通過合理調用接口，簡化用戶操作界面，解決了終端機不能輸入漢字，而充值需要輸入姓名問題。
應用平臺是在終端機上，它與PC和手機不同是具有一下幾個特征：
1.屏幕大，相應的按鈕與文字都比其他平臺要大，觸屏的敏感度不如手機，操作的精準度不如PC，所以要做到盡量少的輸入。
2.不能輸入漢字。
3.根據用戶使用終端設計的場景，核心用戶為中老年人，會在相對固定的場所，以站立的方式在屏幕前操作，會有工作人員協助操作，可能會遇到后方排隊的現象，所以操作盡量直觀簡化，防止用戶出現焦慮等情緒。
帶著這些特點與場景，那么進行一次產品設計吧。
首先根據業務部門提出來的需求，只做中石化的充值卡，并且是以固定面額進行充值，這是一個大前提。之后就去了解了一下，目前PC或手機上加油卡充值的大概操作流程。
具體的操作流程
輸入卡號——確認卡號——選擇金額（輸入金額）——輸入手機號——接受驗證碼——確認并支付——到網點圈存
好像輸入的地方有點多，想一想根據終端機的特性，能不能進行簡化呢？帶著這個問題，再回頭來看看接口文檔與加油卡相關的接口都有哪些。
經過查看發現，關于加油卡充值接口有兩個，一個是充值接口、一個是卡號信息查詢接口。
信息查詢接口主要功能就是輸入19位的卡號后，返回給我們卡主的真實姓名。因為我們都知道中石化的卡辦理是需要身份證實名認證的，所以這個功能實際上能夠幫助用戶確認自己輸入的卡號是否正確。
好，我們記下這個功能以及他能解決的問題。
再看加油卡充值接口。因為一些原因這里就不給大家貼圖了。不過可以說一下這個接口需要的參數都有哪些，包括，cardid這個參數來決定你是需要任意金額充值，還是固定面值的充值。另外就是卡號，加油卡類型等參數。
不過值得注意的是我發現在接口里有個參數需要輸入手機號碼與持卡人姓名。他們是否是必填項呢？接口沒有寫清楚。而且終端機不能輸入漢字的規則，如果要輸入姓名，這將是一個不能完成的任務了啊，除非接口方更改規則。
似乎產品走到這里，有些地方不太清晰了，那么我們要做什么，當然是溝通嘍。
持卡人手機號是否必填？
是的。
用來做什么的呢？
中石化會給這個手機號發送充值成功的短信。
好的，謝謝。
那持卡人姓名呢？
這個是輔助信息，不是必填項
好的。
這時候顧慮都沒有了，接口貌似能夠順利的使用啦。
功能都確定了之后，想想是否能簡化原有的步驟呢。記得做產品的時候業務部的同事提議讓用戶輸入兩次卡號來確認，因為通常都是這樣做的。這時候就能用到那些寫PM文章里的一句話，需求需要分析，不能拿過來解決方案就用。
如果輸入兩次卡號是為了讓用戶確認自己輸入是否有誤，那么我們可不可以利用卡號查詢接口，來給用戶返回姓名來解決這個問題呢？
實際上根本要滿足他的需求是，讓用戶知自己輸入的卡號無誤。
如此在產品設計上，我就只采用了一次輸入卡號的形式，讓接口返回我真實姓名就好了，而且讓一個人在終端機上輸入兩次19位卡號，那也是一種折磨。
功能確認，操作流程確認了。因為業務流程沿用了之前公司設定好的流程這里就不再贅述。剩下的工作就是畫原型圖了，注意，在畫原型的時候最好加入input的一些規則限制，調用哪些接口，正確與錯誤的提示都是什么？有什么異常狀態，需不需要做友好提示等等。這些交互說明都對前端開發和技術開發是必須要的。
這樣就完成了一次通過調用接口來實現產品功能、設計的一個全過程。
參考資料（點擊可直接進入）
[1] PMnote,《利用「接口」做產品時我們該如何思考？》，人人都是產品經理
[2] LinKiD,《產品經理，你要懂點API接口知識！》，人人都是產品經理
