上一個章節(jié)我們已經初步認知了API，現(xiàn)在我們繼續(xù)了解API，通過閱讀，分析，理解，再到應用系統(tǒng)的討論。

前期準備

在正式接觸API前我們需要進行一些前期準備，主要分為賬戶準備，基礎認知。

前者主要包含提前到OTA開發(fā)平臺注冊，獲取到沙箱環(huán)境、正式環(huán)境的相關參數(shù)，準備好技術文檔，溝通流程建立（群組溝通、工單溝通）、費用結算計劃。

后者包含簡單從全局的角度來評估可能用到的接口類型和個數(shù)，例如訂單推送金額是客人支付金額還是扣點后金額來決定數(shù)據(jù)解析的形式，并且當有多個接口可以獲取同一參數(shù)時如何最大化利用，尋求最高效的解決方案。

對API有基本的認知。例如，數(shù)據(jù)獲取或交互是post還是get,是需要訂閱還是全部統(tǒng)一回調，這一點非常重要會影響到整體的設計或優(yōu)化。例如，某平臺的訂單支付消息是需要自行訂閱的，如果不訂閱則需要自行設計過濾邏輯來固定時間篩選已支付訂單（資源浪費），但另外一個平臺卻又是統(tǒng)一的回調指定地址。此時，因為地址只有一個但是回調數(shù)據(jù)確設計N個接口，我們就需要根據(jù)數(shù)據(jù)結構的差別對同一個回調地址的不同數(shù)據(jù)進行解析后用于不同的功能上。

此外數(shù)據(jù)響應同步/異步的取舍，也直接影響到后續(xù)的數(shù)據(jù)處理與數(shù)據(jù)補償。例如，有庫存限制的產品通常采用異步返回的處理模式，既能保證響應速度也能保證響應正確率。

• 示例A：所有垃圾都被扔進了一個垃圾桶，我們需要一個人躲在后面根據(jù)相關參數(shù)進行垃圾分類：干垃圾、濕垃圾、廚余垃圾等等，這個就是一個回調地址的多種數(shù)據(jù)結構解析。
• 示例B：考試交白卷，老師馬上給你打一個0分；考試全部亂選，老師先給你說等我對一下答案，稍后還是給你打一個0分；雖然結果都一樣，但是前者同步返回確認結果，主要應用于100%確認結果的，后者是異步返回，需要有一定內部處理機制。

API解析

此時進入了最關鍵的環(huán)節(jié)，即充分去了解API文檔。此處的了解并不是技術上的認知，而是將API與業(yè)務功能上的融合。

此時，我們將分為三個階段去深入解析API。

階段一

接口描述：了解接口的主要用途與范圍，注意關鍵點例如收費模式、申請資格。

接口地址：識別關鍵字段，便于在日志分析中快速匹配接口。

請求方法與請求參數(shù)：方法主要為get與post;請求參數(shù)力求以最簡單的數(shù)據(jù)獲取更多的內容，例如訂單號、產品編號、交易流水號就可以獲取到整個結構信息。

響應參數(shù)：參數(shù)的響應其實并不是簡單的成功、失敗，更多的其實包含了一些中間狀態(tài)，比如某平臺產品更新接口可能會返回處理中，那這樣的數(shù)據(jù)需要二次核驗是否更新成功。

錯誤代碼：錯誤代碼解析也是提高生產力的優(yōu)化點，一般來說錯誤代碼為純數(shù)字，其表達的意思也是比較技術的例如超時，無響應等，此類報錯直接拋出將會讓業(yè)務人員一臉懵，適當對錯誤代碼優(yōu)化可能大大提高用戶體驗，例如我們對超時重試的溫馨提示為：App發(fā)送超時,系統(tǒng)將自動發(fā)起重試，可忽略此條消息。

階段二

Jason響應的重要性，為什么我會提這個問題？

這個不是開發(fā)關注的嗎？

大錯特錯，作為一個優(yōu)秀的產品經理，具備一定的報文閱讀能力是很有必要的。

閱讀報文的好處：

1）形象化的數(shù)據(jù)展示，變相的可視化數(shù)據(jù)

在需求的前期，功能的不完善會導致數(shù)據(jù)缺失。此時，我們并不能在腦海里快速構建一個完整的三位立體的結構。面對技術化的字段名稱，一個個去理解其含義與用處，既耗時又容易遺忘。

如果我們與開發(fā)小哥通力合作，快速的調通接口，獲取到原始數(shù)據(jù)，猶如將枯燥的文檔化為了一條條鮮活的數(shù)據(jù)。

此時，將報文數(shù)據(jù)轉化為jason后放置到解析網站，立等可取——換一種方式來閱讀文檔，更加靈活。對比字段的表述與實際展示，更容易理解字段所表達的功能點。

2）快速熟悉掌握對方的API結構

Jason閱讀下的另外一個好處是可以以每一個節(jié)點收起或展開報文，類似于腦圖的操作下。我們可以快速理解對方的API結構，例如出行人與訂單的關系、附加信息與訂單關系是存在于訂單級別還是SKU級別還是出行人級別等，方便我們對照自己的訂單結構進行快速解析。

3）有具體的實戰(zhàn)場景去窮舉各種可能

做API對接最忌諱啥？面對文檔空想各種可能，自己主觀揣測返回可能值；對方答疑最討厭什么？并不是實時，可能要等很久，怎么什么都問，不是文檔里面有嗎？

自己怎么解決？

跟開發(fā)一起調通API后就可以進行數(shù)據(jù)模擬了，凡是拿不準的結構，拿不準的返回值都可以根據(jù)業(yè)務演示一遍，獲取到準確的返回便于一次性解析到位，窮舉各種場景，避免遺漏。

階段三

通過上述研究對API文檔有了大概了解會就需要進行結構化的總結與分析，著重兩個相反方面的總結。

1）功能的匹配度

大致對自己需要解析的數(shù)據(jù)進行評估，目前使用的接口是否可以實現(xiàn)功能？匹配度是多少；因為不同的系統(tǒng)之間肯定存在差異，我們有必要提前評估兩個系統(tǒng)的兼容程度來確認人力的投入。

例如目前的解析難度有多大？

首先，看使用的接口數(shù)量，力求最少的接口解決最多的問題，接口數(shù)量增多則勢必增加響應速度（這里并不是嚴格只接口響應速度，而是對接口之間的調用邏輯相互疊加后增加了復雜度，內部判斷延長增加了各種超時響應的可能性）。

其次，還應該提前做好映射準備，做API的勢必離不開映射，映射能很好解決不同系統(tǒng)間相互兼容問題的，簡單的理解如下。

兒子：媽，明天早上有重要的事，八點鐘一定要叫醒我。

媽媽：好的，那你不要睡懶覺哦。

……

媽媽：快起床，都已經八點半了。

兒子心急火燎收拾完沖出家門，一看才七點半不到。

在這個梗中，我們可以認識到在兒子的自身系統(tǒng)中的八點，在媽媽的系統(tǒng)中自動映射成了七點了。雖然沒有直觀的可視化，但是我們可以明顯感受到通過兩個系統(tǒng)的傳遞高效的實現(xiàn)了叫兒子起床的任務。

最后，因為涉及商品、訂單的參數(shù)還是比較多的，相關映射一定要提前做準備，在產品結構設計中就要全盤考慮，并在開發(fā)階段準備好數(shù)據(jù)與映射關系。

2）結果差異化

差異化=1-匹配度

前文說了匹配，這里我們說差異，每個系統(tǒng)都有自己不同于其他系統(tǒng)的特征，這對于我們來說將是非常棘手的問題，因為一旦差異化的出現(xiàn)也就表示系統(tǒng)對接過程中遇到問題，要么更換接口曲線救國，要么就要針對差異化給出自己的解決方案。此時整個API的核心本質凸顯：解決差異，實現(xiàn)統(tǒng)一。

例如，我們在某平臺對接的時候發(fā)現(xiàn)其訂單的補差價（購買后需要再補一筆錢）功能沒有相關接口通知，那即使有補差訂單接口，無法知道訂單號，明顯邏輯有問題。我們采取的方案分為兩條線，第一條向平臺反饋，提出問題（截止筆者發(fā)稿時已經解決），第二條自身因為補差通常由商家向客人發(fā)起，所以我們自己是知道的，所以當客人補差完成時我們設置一個通知按鈕來替代。

歸納總結

就跟寫作文一樣，往往到了最后我們需要進行上下文的總結，來再次確認主題，呼應主題。

我們一般從三個方面來進行。

與對方技術支持進行溝通處理

經過上面的梳理，我們勢必會對API文檔里面的相關報文或者表達意思有異議，此時可以向對方技術支持提問來搞定，并且可以測試一下溝通流程，固定流程。

大家覺得不就是溝通而已，為什么還要這么正式？

簡單思考一個問題，為什么很多開發(fā)平臺要么嚴格走工單這種效率低的溝通方式？

要么走及時溝通工具快速解決問題呢？

工單溝通既可以統(tǒng)計自身處理效率，也可以為提問方建立小型“知識庫”，便于后期自查。

溝通工具便于前期平臺搭建時與種子用戶、核心用戶交流，快速響應，弊端是反復問反復回答同一類型問題。所以，大家在溝通環(huán)節(jié)一定要注意，例如工單一定要進行提前量，例如我方開發(fā)可能需要較多時間排查問題時，可以先提交工單節(jié)約時間，提高效率。

與我方技術探討

產品經理不光是功能的締造者，更是交流的橋梁。當我們獲取到整體的API框架時，在評審前后我們勢必還是需要與開發(fā)非正式的探討一些我們關系的話題。

例如，數(shù)據(jù)接入后的可視化問題，數(shù)據(jù)不可能永遠不“見光”，可視化需要考慮的是數(shù)據(jù)展示的友好化，業(yè)務的連續(xù)性；前者強調如何將枯燥的數(shù)據(jù)進行便于理解的展示。

例如，當我們向某平臺推送產品時，我們在可視化頁面會展示很多字段，A字段的值固定且灰色顯示，這個表示我們只能閱讀而不能修改，B字段的值有下劃線，鼠標移動有光標閃爍表示可以修改；后者可理解為我們對API解析的數(shù)據(jù)不是為了存儲，而是為了進一步的利用，例如當我們把訂單獲取到我們的頁面展示后還要紅色字體提示最晚確認時間，便于客服進行下一步處理。

與我司業(yè)務探討

技術層面的溝通完畢后，我們需要有一個交代，也就是對業(yè)務的回復。

告知其整體項目的難度，便于其有一個心理預期，其次還需要表明自己需要的支持，例如需要聯(lián)系對方溝通、配合準備數(shù)據(jù)等。

技術側的理解

在API解決方案成型前，我們需要站在技術的角度上與開發(fā)人員反復溝通，宣講我們的思路，推動我們的方案，讓開發(fā)人員理解我們需要實現(xiàn)的系統(tǒng)大概雛形，以及產品經理的解決方案。避免脫離業(yè)務來寫代碼。

此時我們再回到上一節(jié)講過的重點即系統(tǒng)的整體架構設計。后續(xù)我們也會以全新打造自研ERP為例來進行舉例講解。

業(yè)務方想要的是快速推送產品，并及時確認訂單——>通過對接各個平臺產品API接口推送產品信息、通過訂單API接口解析訂單信息并形成交互——>在梳理過程中發(fā)現(xiàn)后期的收付款財務模板被業(yè)務方忽略了，需要我們一并解決（隱藏需求）——>堅持內外不相擾的策略，需要有一個中間庫處理平臺來處理輸出標準信息到ERP實現(xiàn)內外數(shù)據(jù)互通互融。

整體系統(tǒng)框架

此時，再來閱讀整個系統(tǒng)，我們可以清晰的梳理出單個平臺的處理流程以及整個系統(tǒng)的后期可拓展性。

堅持“殊途同歸”的思想，外部平臺無論有什么特征，都到中間庫進行標準化作業(yè)后輸出符合自身ERP要求的數(shù)據(jù)進行處理即可。

對于新系統(tǒng)可以具備強大的可拓展性，對外可輕松接入其他平臺，對內可完美兼容自身訂單；對于已存在系統(tǒng)，不影響原系統(tǒng)下僅需小成本改造。

實戰(zhàn)案例

后面三篇文章，筆者將分別對三個OTA平臺（小海豚、小佩奇、小蜜蜂），各自摘取關鍵的API信息，從產品自動推送、訂單自動化流轉、財務自動對賬三個方向實戰(zhàn)講解。

#相關閱讀#

OTA實戰(zhàn)分解（1）：快速閱讀API及場景應用

本文由 @寒松 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協(xié)議