做產(chǎn)品助理之后接的第一個(gè)產(chǎn)品就與“API接口”有關(guān)。剛做的時(shí)候，稀里糊涂，后來(lái)各種噴過(guò)后，才慢慢理解了“接口”這個(gè)東西。都說(shuō)產(chǎn)品只需要“了解”技術(shù)就可以，不需要自己會(huì )寫(xiě)。所以不知羞恥的我對這東西也只知表皮啦。做到懂得基本原理，會(huì )看，會(huì )用，就好了。

如果你和我一樣是個(gè)技術(shù)盲，那么我們要先來(lái)掃盲一下了。API（Application Programming Interface,應用程序編程接口）是一些預先定義的函數，目的是提供應用程序與開(kāi)發(fā)人員基于某軟件或硬件得以訪(fǎng)問(wèn)一組例程的能力，而又無(wú)需訪(fǎng)問(wèn)源碼，或理解內部工作機制的細節。有點(diǎn)復雜。

簡(jiǎn)單的說(shuō)，開(kāi)放接口是一個(gè)抽象的概念，直接聽(tīng)名字就知道他是為了連接而開(kāi)放的入口，以讓別人的程序能夠調用你的程序數據。就像你的電腦、手機有一些USB接口，也可以說(shuō)是開(kāi)放了接口，有了這些接口別人就可以用他來(lái)做插U盤(pán)或充電等功能。只是說(shuō)API不是硬件接口，而是程序軟件接口罷了。

這里給大家舉個(gè)例子，蓄水池與水泵。如果把提供接口的一方，比作蓄水池，那么池子里裝的就是一些封裝好的數據啊函數之類(lèi)之類(lèi)。這時(shí)候如果蓄水池想把他的水，分享給其他人，他就需要在自己身上造個(gè)出水口，這個(gè)出水口就是所謂的接口。

這時(shí)候水泵出場(chǎng)了，水泵很需要這些水，他找來(lái)了一個(gè)水管用來(lái)把水抽出來(lái)，這時(shí)候水泵發(fā)送一個(gè)指令，蓄水池就會(huì )放出一點(diǎn)水。同樣，今天你想要水，明天你想要果汁，都需要通過(guò)指令來(lái)命令蓄水池。這樣的一去一回，就完成了一次對接口的交互。

可能說(shuō)的不是很?chē)乐?，但是你能懂個(gè)大概意思就可以了。大概的原理我們懂了。那如果拿到一個(gè)接口文檔我們該如何來(lái)閱讀呢？

一個(gè)比較專(zhuān)業(yè)的文檔都會(huì )寫(xiě)上各種補充說(shuō)明輔助你理解，比如接口使用的協(xié)議、格式、接口應答返回的數據格式等等。

拿一個(gè)手頭的接口文檔給大家看看，比較正規的文檔格式：

小白大呼看不懂這些奇怪的文字，那么下面就教你如何看懂這些參數。一般接口包含以下幾個(gè)內容：

接口地址

顧名思義就是接口的地址，以網(wǎng)址的形式展現，你通過(guò)發(fā)送請求給這個(gè)網(wǎng)址來(lái)對接口進(jìn)行交互操作。

請求方法

請求指令可以用很多種語(yǔ)言來(lái)寫(xiě)，一般有curl、php、python、java等等，而與我們合作的接口方提供的就是curl的方式。很多產(chǎn)品都會(huì )聽(tīng)到技術(shù)說(shuō)這個(gè)用POST傳輸，那個(gè)用GET傳輸，那么什么是POST和GET呢？

我們通常說(shuō)的http傳輸形式最基本的方法有4種，分別是GET，POST，PUT，DELETE。我們可以這樣認為：一個(gè)URL地址，它用于描述一個(gè)網(wǎng)絡(luò )上的資源，而HTTP中的GET，POST，PUT，DELETE就對應著(zhù)對這個(gè)資源的查，改，增，刪4個(gè)操作。

GET一般用于獲取/查詢(xún)資源信息，而POST一般用于更新資源信息。不過(guò)對資源的增，刪，改，查操作，其實(shí)都可以通過(guò)GET/POST完成，不需要用到PUT和DELETE。

所以一般我們只會(huì )看到GET和POST兩種。兩者的區別在于get多用于查詢(xún)，而POST多余用對資源進(jìn)行修改的操作。比如一般的天氣查詢(xún)，賬號金額查詢(xún)都以GET形式傳輸，比如登陸信息的傳輸就會(huì )用到POST。

更直觀(guān)的區別去兩者的話(huà)，GET請求的數據會(huì )附在URL之后，以?分割URL和傳輸數據，參數之間以&相連，如：xxxx.ha?userid=PMnote&userpws=123456&version=6.0。如果數據是英文字母/數字，原樣發(fā)送，如果是空格，轉換為+，如果是中文/其他字符，則直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX為該符號以16進(jìn)制表示的ASCII。而POST把提交的數據則放置在是HTTP包的包體中。

請求參數

即傳輸參數的時(shí)候要帶的一些參數，一般文檔中會(huì )用表格的形式清晰的說(shuō)明。當我向接口發(fā)送攜帶請求參數的請求時(shí)，都要攜帶什么字段，規則是什么。如下圖：

返回內容

返回內容一般會(huì )以json或是XML的形式返回。

上圖就是以XML的形式返回的。

像上面貼出來(lái)的這種接口，還是比較好閱讀的。如果我們發(fā)送userid和userpws，就是用戶(hù)名和密碼給接口，接口就返回給我們err_msg為空，則說(shuō)明正確，retconde也返回1說(shuō)明也成功了。

如果錯誤則retcond返回空，如果出現其他錯誤就可以查詢(xún)具體的錯誤代碼提示內容了。ret_leftcredit則返回了352328.97的數字，這就是這個(gè)賬戶(hù)中的余額啦。

所以可以看出該接口主要是為了查詢(xún)余額而用，使用了GET方式，傳過(guò)去用戶(hù)名和密碼，返回正確或錯誤，如果正確則顯示余額，錯誤顯示錯誤信息。

錯誤代碼

最后是錯誤代碼，一般都會(huì )附在接口文檔的最后，如果在測試或是上線(xiàn)后，可以根據返回接口查看問(wèn)題。也可以在設計產(chǎn)品時(shí)將錯誤的狀態(tài)顯示在前端。

知道了接口的原理，看到了接口的各種參數和規則。接下來(lái)就到了實(shí)戰了。

接口是如何應用在產(chǎn)品設計當中的呢？

請先記?。航涌跊Q定功能，接口決定功能，接口決定功能。重要的事情要說(shuō)三遍。

筆者在第一次碰接口的時(shí)候就傻傻的去照抄了其他網(wǎng)站的一些功能和驗證方法，沒(méi)有做好最初與接口方和技術(shù)的溝通工作，結果在評審的時(shí)候就被噴的體無(wú)完膚了。

“你確定接口有這個(gè)功能嗎？”“這個(gè)接口是實(shí)現不了這個(gè)功能的?！?/span>所以在產(chǎn)品設計之初就要先透徹了解手中的接口文檔中的接口是否具有你想要的功能。

下面以一個(gè)加油卡充值來(lái)舉個(gè)實(shí)戰案例。這是我最初所負責的加油卡虛擬充值服務(wù)。應用平臺是在終端機上，它與PC和手機不同是具有一下幾個(gè)特征：

屏幕大，相應的按鈕與文字都比其他平臺要大，觸屏的敏感度不如手機，操作的精準度不如PC，所以要做到盡量少的輸入。

不能輸入漢字。根據用戶(hù)使用終端設計的場(chǎng)景，核心用戶(hù)為中老年人，會(huì )在相對固定的場(chǎng)所，以站立的方式在屏幕前操作，會(huì )有工作人員協(xié)助操作，可能會(huì )遇到后方排隊的現象，所以操作盡量直觀(guān)簡(jiǎn)化，放置用戶(hù)出現焦慮等情緒。

帶著(zhù)這些特點(diǎn)與場(chǎng)景，那么進(jìn)行一次產(chǎn)品設計吧。

首先根據業(yè)務(wù)部門(mén)提出來(lái)的需求，我們只做中石化的充值卡，并且是以固定面額進(jìn)行充值，這是一個(gè)大前提。之后就去了解了一下，目前PC或手機上加油卡充值的大概操作流程。

這是中石化網(wǎng)上營(yíng)業(yè)廳的一個(gè)截圖

具體的操作流程：輸入卡號——確認卡號——選擇金額（輸入金額）——輸入手機號——接受驗證碼——確認并支付——到網(wǎng)點(diǎn)圈存

好像輸入的地方有點(diǎn)多，想一想根據終端機的特性，能不能進(jìn)行簡(jiǎn)化呢？帶著(zhù)這個(gè)問(wèn)題，再回頭來(lái)看看接口文檔與加油卡相關(guān)的接口都有哪些。

經(jīng)過(guò)查看發(fā)現，關(guān)于加油卡充值接口有兩個(gè)，一個(gè)是充值接口、一個(gè)是卡號信息查詢(xún)接口。

信息查詢(xún)接口主要功能就是輸入19位的卡號后，返回給我們卡主的真實(shí)姓名。因為我們都知道中石化的卡辦理是需要身份證實(shí)名認證的，所以這個(gè)功能實(shí)際上能夠幫助用戶(hù)確認自己輸入的卡號是否正確。

好，我們記下這個(gè)功能以及他能解決的問(wèn)題。再看加油卡充值接口。因為一些原因這里就不給大家貼圖了。不過(guò)可以說(shuō)一下這個(gè)接口需要的參數都有哪些，包括，cardid這個(gè)參數來(lái)決定你是需要任意金額充值，還是固定面值的充值。另外就是卡號，加油卡類(lèi)型等參數。

不過(guò)值得注意的是我發(fā)現在接口里有個(gè)參數需要輸入手機號碼與持卡人姓名。他們是否是必填項呢？接口沒(méi)有寫(xiě)清楚。而且終端機不能輸入漢字的規則，如果要輸入姓名，這將是一個(gè)不能完成的任務(wù)了啊，除非接口方更改規則。

似乎產(chǎn)品走到這里，有些地方不太清晰了，那么我們要做什么，當然是溝通嘍。

持卡人手機號是否必填？是的。用來(lái)做什么的呢？

中石化會(huì )給這個(gè)手機號發(fā)送充值成功的短信。好的，謝謝。

那持卡人姓名呢？這個(gè)是輔助信息，不是必填項，好的。這時(shí)候顧慮都沒(méi)有了，接口貌似能夠順利的使用啦。

功能都確定了之后，想想是否能簡(jiǎn)化原有的步驟呢。記得做產(chǎn)品的時(shí)候業(yè)務(wù)部的同事提議讓用戶(hù)輸入兩次卡號來(lái)確認，因為通常都是這樣做的。這時(shí)候就能用到那些寫(xiě)PM文章里的一句話(huà)，需求需要分析，不能拿過(guò)來(lái)解決方案就用。

如果輸入兩次卡號是為了讓用戶(hù)確認自己輸入是否有誤，那么我們可不可以利用卡號查詢(xún)接口，來(lái)給用戶(hù)返回姓名來(lái)解決這個(gè)問(wèn)題呢？

實(shí)際上根本要滿(mǎn)足他的需求是，讓用戶(hù)知自己輸入的卡號無(wú)誤。如此在產(chǎn)品設計上，我就只采用了一次輸入卡號的形式，讓接口返回我真實(shí)姓名就好了，而且讓一個(gè)人在終端機上輸入兩次19位卡號，那也是一種折磨。

功能確認，操作流程確認了。因為業(yè)務(wù)流程沿用了之前公司設定好的流程這里就不再贅述。剩下的工作就是畫(huà)原型圖了，注意，在畫(huà)原型的時(shí)候最好加入input的一些規則限制，調用哪些接口，正確與錯誤的提示都是什么？有什么異常狀態(tài)，需不需要做友好提示等等。

這些交互說(shuō)明都對前端開(kāi)發(fā)和技術(shù)開(kāi)發(fā)是必須要的。這樣就完成了一次通過(guò)調用接口來(lái)實(shí)現產(chǎn)品功能、設計的一個(gè)全過(guò)程。