做產(chǎn)品助理之后接的第一個產(chǎn)品就與“API接口”有關(guān)。剛做的時候，稀里糊涂，后來各種噴過后，才慢慢理解了“接口”這個東西。都說產(chǎn)品只需要“了解”技術(shù)就可以，不需要自己會寫。所以不知羞恥的我對這東西也只知表皮啦。做到懂得基本原理，會看，會用，就好了。
如果你和我一樣是個技術(shù)盲，那么我們要先來掃盲一下了。
恩。有點復雜
簡單的說，開放接口是一個抽象的概念，直接聽名字就知道他是為了連接而開放的入口，以讓別人的程序能夠調(diào)用你的程序數(shù)據(jù)。就像你的電腦、手機有一些USB接口，也可以說是開放了接口，有了這些接口別人就可以用他來做插U盤或充電等功能。只是說API不是硬件接口，而是程序軟件接口罷了。
這里給大家舉個例子，蓄水池與水泵。
如果把提供接口的一方，比作蓄水池，那么池子里裝的就是一些封裝好的數(shù)據(jù)啊函數(shù)之類之類。這時候如果蓄水池想把他的水，分享給其他人，他就需要在自己身上造個出水口，這個出水口就是所謂的接口。
這時候水泵出場了，水泵很需要這些水，他找來了一個水管用來把水抽出來，這時候水泵發(fā)送一個指令，蓄水池就會放出一點水。同樣，今天你想要水，明天你想要果汁，都需要通過指令來命令蓄水池。
這樣的一去一回，就完成了一次對接口的交互。
可能說的不是很嚴謹，但是你能懂個大概意思就可以了。
大概的原理我們懂了。那如果拿到一個接口文檔我們該如何來閱讀呢？
一個比較專業(yè)的文檔都會寫上各種補充說明輔助你理解，比如接口使用的協(xié)議、格式、接口應答返回的數(shù)據(jù)格式等等。
拿一個手頭的接口文檔給大家看看，比較正規(guī)的文檔格式：
小白大呼看不懂這些奇怪的文字，那么下面就教你如何看懂這些參數(shù)。
一般接口包含以下幾個內(nèi)容：
接口地址 請求方法 請求參數(shù) 返回內(nèi)容 錯誤代碼接口地址
顧名思義就是接口的地址，以網(wǎng)址的形式展現(xiàn)，你通過發(fā)送請求給這個網(wǎng)址來對接口進行交互操作。
請求方法
請求指令可以用很多種語言來寫，一般有curl、php、python、java等等，而與我們合作的接口方提供的就是curl的方式。
如下圖，就是典型的curl的GET請求形式。
很多產(chǎn)品都會聽到技術(shù)說這個用POST傳輸，那個用GET傳輸，那么什么是POST和GET呢？
我們通常說的http傳輸形式最基本的方法有4種，分別是GET，POST，PUT，DELETE。我們可以這樣認為：一個URL地址，它用于描述一個網(wǎng)絡(luò)上的資源，而HTTP中的GET，POST，PUT，DELETE就對應著對這個資源的查，改，增，刪4個操作。
GET一般用于獲取/查詢資源信息，而POST一般用于更新資源信息。不過對資源的增，刪，改，查操作，其實都可以通過GET/POST完成，不需要用到PUT和DELETE。
所以一般我們只會看到GET和POST兩種。兩者的區(qū)別在于get多用于查詢，而POST多余用對資源進行修改的操作。比如一般的天氣查詢，賬號金額查詢都以GET形式傳輸，比如登陸信息的傳輸就會用到POST。
更直觀的區(qū)別去兩者的話，GET請求的數(shù)據(jù)會附在URL之后，以?分割URL和傳輸數(shù)據(jù)，參數(shù)之間以&相連，如：xxxx.ha?userid=PMnote&userpws=123456&version=6.0。如果數(shù)據(jù)是英文字母/數(shù)字，原樣發(fā)送，如果是空格，轉(zhuǎn)換為+，如果是中文/其他字符，則直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX為該符號以16進制表示的ASCII。而POST把提交的數(shù)據(jù)則放置在是HTTP包的包體中。
請求參數(shù)
即傳輸參數(shù)的時候要帶的一些參數(shù)，一般文檔中會用表格的形式清晰的說明。當我向接口發(fā)送攜帶請求參數(shù)的請求時，都要攜帶什么字段，規(guī)則是什么。如下圖：
返回內(nèi)容
返回內(nèi)容一般會以json或是XML的形式返回。
上圖就是以XML的形式返回的。
像上面貼出來的這種接口，還是比較好閱讀的。如果我們發(fā)送userid和userpws，就是用戶名和密碼給接口，接口就返回給我們err_msg為空，則說明正確，retconde也返回1說明也成功了。
如果錯誤則retcond返回空，如果出現(xiàn)其他錯誤就可以查詢具體的錯誤代碼提示內(nèi)容了。ret_leftcredit則返回了352328.97的數(shù)字，這就是這個賬戶中的余額啦。
所以可以看出該接口主要是為了查詢余額而用，使用了GET方式，傳過去用戶名和密碼，返回正確或錯誤，如果正確則顯示余額，錯誤顯示錯誤信息。
是不是很容易理解啦。
錯誤代碼
最后是錯誤代碼，一般都會附在接口文檔的最后，如果在測試或是上線后，可以根據(jù)返回接口查看問題。也可以在設(shè)計產(chǎn)品時將錯誤的狀態(tài)顯示在前端。
知道了接口的原理，看到了接口的各種參數(shù)和規(guī)則。
接下來就到了實戰(zhàn)了。
接口是如何應用在產(chǎn)品設(shè)計當中的呢？
請先記住，接口決定功能，接口決定功能，接口決定功能。重要的事情要說三遍。
筆者在第一次碰接口的時候就傻傻的去照抄了其他網(wǎng)站的一些功能和驗證方法，沒有做好最初與接口方和技術(shù)的溝通工作，結(jié)果在評審的時候就被噴的體無完膚了。
“你確定接口有這個功能嗎？” “這個接口是實現(xiàn)不了這個功能的。”
所以在產(chǎn)品設(shè)計之初就要先透徹了解手中的接口文檔中的接口是否具有你想要的功能。
下面以一個加油卡充值來舉個實戰(zhàn)案例。這是我最初所負責的加油卡虛擬充值服務。
應用平臺是在終端機上，它與PC和手機不同是具有一下幾個特征：
屏幕大，相應的按鈕與文字都比其他平臺要大，觸屏的敏感度不如手機，操作的精準度不如PC，所以要做到盡量少的輸入。 不能輸入漢字。 根據(jù)用戶使用終端設(shè)計的場景，核心用戶為中老年人，會在相對固定的場所，以站立的方式在屏幕前操作，會有工作人員協(xié)助操作，可能會遇到后方排隊的現(xiàn)象，所以操作盡量直觀簡化，放置用戶出現(xiàn)焦慮等情緒。帶著這些特點與場景，那么進行一次產(chǎn)品設(shè)計吧。
首先根據(jù)業(yè)務部門提出來的需求，我們只做中石化的充值卡，并且是以固定面額進行充值，這是一個大前提。之后就去了解了一下，目前PC或手機上加油卡充值的大概操作流程。
具體的操作流程
輸入卡號——確認卡號——選擇金額（輸入金額）——輸入手機號——接受驗證碼——確認并支付——到網(wǎng)點圈存
好像輸入的地方有點多，想一想根據(jù)終端機的特性，能不能進行簡化呢？帶著這個問題，再回頭來看看接口文檔與加油卡相關(guān)的接口都有哪些。
經(jīng)過查看發(fā)現(xiàn)，關(guān)于加油卡充值接口有兩個，一個是充值接口、一個是卡號信息查詢接口。
信息查詢接口主要功能就是輸入19位的卡號后，返回給我們卡主的真實姓名。因為我們都知道中石化的卡辦理是需要身份證實名認證的，所以這個功能實際上能夠幫助用戶確認自己輸入的卡號是否正確。 好，我們記下這個功能以及他能解決的問題。
再看加油卡充值接口。因為一些原因這里就不給大家貼圖了。不過可以說一下這個接口需要的參數(shù)都有哪些，包括，cardid這個參數(shù)來決定你是需要任意金額充值，還是固定面值的充值。另外就是卡號，加油卡類型等參數(shù)。
不過值得注意的是我發(fā)現(xiàn)在接口里有個參數(shù)需要輸入手機號碼與持卡人姓名。他們是否是必填項呢？接口沒有寫清楚。而且終端機不能輸入漢字的規(guī)則，如果要輸入姓名，這將是一個不能完成的任務了啊，除非接口方更改規(guī)則。
似乎產(chǎn)品走到這里，有些地方不太清晰了，那么我們要做什么，當然是溝通嘍。
這時候顧慮都沒有了，接口貌似能夠順利的使用啦。
功能都確定了之后，想想是否能簡化原有的步驟呢。記得做產(chǎn)品的時候業(yè)務部的同事提議讓用戶輸入兩次卡號來確認，因為通常都是這樣做的。這時候就能用到那些寫PM文章里的一句話，需求需要分析，不能拿過來解決方案就用。
如果輸入兩次卡號是為了讓用戶確認自己輸入是否有誤，那么我們可不可以利用卡號查詢接口，來給用戶返回姓名來解決這個問題呢？
實際上根本要滿足他的需求是，讓用戶知自己輸入的卡號無誤。
如此在產(chǎn)品設(shè)計上，我就只采用了一次輸入卡號的形式，讓接口返回我真實姓名就好了，而且讓一個人在終端機上輸入兩次19位卡號，那也是一種折磨。
功能確認，操作流程確認了。因為業(yè)務流程沿用了之前公司設(shè)定好的流程這里就不再贅述。剩下的工作就是畫原型圖了，注意，在畫原型的時候最好加入input的一些規(guī)則限制，調(diào)用哪些接口，正確與錯誤的提示都是什么？有什么異常狀態(tài)，需不需要做友好提示等等。這些交互說明都對前端開發(fā)和技術(shù)開發(fā)是必須要的。
這樣就完成了一次通過調(diào)用接口來實現(xiàn)產(chǎn)品功能、設(shè)計的一個全過程。
重慶分公司
重慶分公司
