午夜免费电影-中文字幕丰满乱孑伦无码专区-久久久久久亚洲精品无码-国产精品天天狠天天看

做產品助理之后接的第一個產品就與“API接口”有關。剛做的時候，稀里糊涂，后來各種噴過后，才慢慢理解了“接口”這個東西。都說產品只需要“了解”技術就可以，不需要自己會寫。所以不知羞恥的我對這東西也只知表皮啦。做到懂得基本原理，會看，會用，就好了。

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

簡單的說，開放接口是一個抽象的概念，直接聽名字就知道他是為了連接而開放的入口，以讓別人的程序能夠調用你的程序數據。就像你的電腦、手機有一些USB接口，也可以說是開放了接口，有了這些接口別人就可以用他來做插U盤或充電等功能。只是說API不是硬件接口，而是程序軟件接口罷了。

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

這時候水泵出場了，水泵很需要這些水，他找來了一個水管用來把水抽出來，這時候水泵發送一個指令，蓄水池就會放出一點水。同樣，今天你想要水，明天你想要果汁，都需要通過指令來命令蓄水池。這樣的一去一回，就完成了一次對接口的交互。

可能說的不是很嚴謹，但是你能懂個大概意思就可以了。大概的原理我們懂了。那如果拿到一個接口文檔我們該如何來閱讀呢？

一個比較專業的文檔都會寫上各種補充說明輔助你理解，比如接口使用的協議、格式、接口應答返回的數據格式等等。

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

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

接口地址

顧名思義就是接口的地址，以網址的形式展現，你通過發送請求給這個網址來對接口進行交互操作。

請求方法

請求指令可以用很多種語言來寫，一般有curl、php、python、java等等，而與我們合作的接口方提供的就是curl的方式。很多產品都會聽到技術說這個用POST傳輸，那個用GET傳輸，那么什么是POST和GET呢？

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

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

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

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

請求參數

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

返回內容

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

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

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

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

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

錯誤代碼

最后是錯誤代碼，一般都會附在接口文檔的最后，如果在測試或是上線后，可以根據返回接口查看問題。也可以在設計產品時將錯誤的狀態顯示在前端。

知道了接口的原理，看到了接口的各種參數和規則。接下來就到了實戰了。

接口是如何應用在產品設計當中的呢？

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

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

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

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

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

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

帶著這些特點與場景，那么進行一次產品設計吧。

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

這是中石化網上營業廳的一個截圖

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

好像輸入的地方有點多，想一想根據終端機的特性，能不能進行簡化呢？帶著這個問題，再回頭來看看接口文檔與加油卡相關的接口都有哪些。

經過查看發現，關于加油卡充值接口有兩個，一個是充值接口、一個是卡號信息查詢接口。

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

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

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

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

持卡人手機號是否必填？是的。用來做什么的呢？

中石化會給這個手機號發送充值成功的短信。好的，謝謝。

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

功能都確定了之后，想想是否能簡化原有的步驟呢。記得做產品的時候業務部的同事提議讓用戶輸入兩次卡號來確認，因為通常都是這樣做的。這時候就能用到那些寫PM文章里的一句話，需求需要分析，不能拿過來解決方案就用。

如果輸入兩次卡號是為了讓用戶確認自己輸入是否有誤，那么我們可不可以利用卡號查詢接口，來給用戶返回姓名來解決這個問題呢？

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

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

這些交互說明都對前端開發和技術開發是必須要的。這樣就完成了一次通過調用接口來實現產品功能、設計的一個全過程。