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

前期準(zhǔn)備

在正式接觸API前我們需要進(jìn)行一些前期準(zhǔn)備，主要分為賬戶(hù)準(zhǔn)備，基礎(chǔ)認(rèn)知。

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

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

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

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

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

API解析

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

此時(shí)，我們將分為三個(gè)階段去深入解析API。

階段一

接口描述：了解接口的主要用途與范圍，注意關(guān)鍵點(diǎn)例如收費(fèi)模式、申請(qǐng)資格。

接口地址：識(shí)別關(guān)鍵字段，便于在日志分析中快速匹配接口。

請(qǐng)求方法與請(qǐng)求參數(shù)：方法主要為get與post;請(qǐng)求參數(shù)力求以最簡(jiǎn)單的數(shù)據(jù)獲取更多的內(nèi)容，例如訂單號(hào)、產(chǎn)品編號(hào)、交易流水號(hào)就可以獲取到整個(gè)結(jié)構(gòu)信息。

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

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

階段二

Jason響應(yīng)的重要性，為什么我會(huì)提這個(gè)問(wèn)題？

這個(gè)不是開(kāi)發(fā)關(guān)注的嗎？

大錯(cuò)特錯(cuò)，作為一個(gè)優(yōu)秀的產(chǎn)品經(jīng)理，具備一定的報(bào)文閱讀能力是很有必要的。

閱讀報(bào)文的好處：

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

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

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

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

2）快速熟悉掌握對(duì)方的API結(jié)構(gòu)

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

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

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

自己怎么解決？

跟開(kāi)發(fā)一起調(diào)通API后就可以進(jìn)行數(shù)據(jù)模擬了，凡是拿不準(zhǔn)的結(jié)構(gòu)，拿不準(zhǔn)的返回值都可以根據(jù)業(yè)務(wù)演示一遍，獲取到準(zhǔn)確的返回便于一次性解析到位，窮舉各種場(chǎng)景，避免遺漏。

階段三

通過(guò)上述研究對(duì)API文檔有了大概了解會(huì)就需要進(jìn)行結(jié)構(gòu)化的總結(jié)與分析，著重兩個(gè)相反方面的總結(jié)。

1）功能的匹配度

大致對(duì)自己需要解析的數(shù)據(jù)進(jìn)行評(píng)估，目前使用的接口是否可以實(shí)現(xiàn)功能？匹配度是多少；因?yàn)椴煌南到y(tǒng)之間肯定存在差異，我們有必要提前評(píng)估兩個(gè)系統(tǒng)的兼容程度來(lái)確認(rèn)人力的投入。

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

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

其次，還應(yīng)該提前做好映射準(zhǔn)備，做API的勢(shì)必離不開(kāi)映射，映射能很好解決不同系統(tǒng)間相互兼容問(wèn)題的，簡(jiǎn)單的理解如下。

兒子：媽?zhuān)魈煸缟嫌兄匾氖拢它c(diǎn)鐘一定要叫醒我。

媽媽?zhuān)汉玫?，那你不要睡懶覺(jué)哦。

……

媽媽?zhuān)嚎炱鸫?，都已?jīng)八點(diǎn)半了。

兒子心急火燎收拾完沖出家門(mén)，一看才七點(diǎn)半不到。

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

最后，因?yàn)樯婕吧唐?、訂單的參?shù)還是比較多的，相關(guān)映射一定要提前做準(zhǔn)備，在產(chǎn)品結(jié)構(gòu)設(shè)計(jì)中就要全盤(pán)考慮，并在開(kāi)發(fā)階段準(zhǔn)備好數(shù)據(jù)與映射關(guān)系。

2）結(jié)果差異化

差異化=1-匹配度

前文說(shuō)了匹配，這里我們說(shuō)差異，每個(gè)系統(tǒng)都有自己不同于其他系統(tǒng)的特征，這對(duì)于我們來(lái)說(shuō)將是非常棘手的問(wèn)題，因?yàn)橐坏┎町惢某霈F(xiàn)也就表示系統(tǒng)對(duì)接過(guò)程中遇到問(wèn)題，要么更換接口曲線救國(guó)，要么就要針對(duì)差異化給出自己的解決方案。此時(shí)整個(gè)API的核心本質(zhì)凸顯：解決差異，實(shí)現(xiàn)統(tǒng)一。

例如，我們?cè)谀称脚_(tái)對(duì)接的時(shí)候發(fā)現(xiàn)其訂單的補(bǔ)差價(jià)（購(gòu)買(mǎi)后需要再補(bǔ)一筆錢(qián)）功能沒(méi)有相關(guān)接口通知，那即使有補(bǔ)差訂單接口，無(wú)法知道訂單號(hào)，明顯邏輯有問(wèn)題。我們采取的方案分為兩條線，第一條向平臺(tái)反饋，提出問(wèn)題（截止筆者發(fā)稿時(shí)已經(jīng)解決），第二條自身因?yàn)檠a(bǔ)差通常由商家向客人發(fā)起，所以我們自己是知道的，所以當(dāng)客人補(bǔ)差完成時(shí)我們?cè)O(shè)置一個(gè)通知按鈕來(lái)替代。

歸納總結(jié)

就跟寫(xiě)作文一樣，往往到了最后我們需要進(jìn)行上下文的總結(jié)，來(lái)再次確認(rèn)主題，呼應(yīng)主題。

我們一般從三個(gè)方面來(lái)進(jìn)行。

與對(duì)方技術(shù)支持進(jìn)行溝通處理

經(jīng)過(guò)上面的梳理，我們勢(shì)必會(huì)對(duì)API文檔里面的相關(guān)報(bào)文或者表達(dá)意思有異議，此時(shí)可以向?qū)Ψ郊夹g(shù)支持提問(wèn)來(lái)搞定，并且可以測(cè)試一下溝通流程，固定流程。

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

簡(jiǎn)單思考一個(gè)問(wèn)題，為什么很多開(kāi)發(fā)平臺(tái)要么嚴(yán)格走工單這種效率低的溝通方式？

要么走及時(shí)溝通工具快速解決問(wèn)題呢？

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

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

與我方技術(shù)探討

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

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

例如，當(dāng)我們向某平臺(tái)推送產(chǎn)品時(shí)，我們?cè)诳梢暬?yè)面會(huì)展示很多字段，A字段的值固定且灰色顯示，這個(gè)表示我們只能閱讀而不能修改，B字段的值有下劃線，鼠標(biāo)移動(dòng)有光標(biāo)閃爍表示可以修改；后者可理解為我們對(duì)API解析的數(shù)據(jù)不是為了存儲(chǔ)，而是為了進(jìn)一步的利用，例如當(dāng)我們把訂單獲取到我們的頁(yè)面展示后還要紅色字體提示最晚確認(rèn)時(shí)間，便于客服進(jìn)行下一步處理。

與我司業(yè)務(wù)探討

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

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

技術(shù)側(cè)的理解

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

此時(shí)我們?cè)倩氐缴弦还?jié)講過(guò)的重點(diǎn)即系統(tǒng)的整體架構(gòu)設(shè)計(jì)。后續(xù)我們也會(huì)以全新打造自研ERP為例來(lái)進(jìn)行舉例講解。

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

整體系統(tǒng)框架

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

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

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

實(shí)戰(zhàn)案例

后面三篇文章，筆者將分別對(duì)三個(gè)OTA平臺(tái)（小海豚、小佩奇、小蜜蜂），各自摘取關(guān)鍵的API信息，從產(chǎn)品自動(dòng)推送、訂單自動(dòng)化流轉(zhuǎn)、財(cái)務(wù)自動(dòng)對(duì)賬三個(gè)方向?qū)崙?zhàn)講解。

#相關(guān)閱讀#

OTA實(shí)戰(zhàn)分解（1）：快速閱讀API及場(chǎng)景應(yīng)用

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

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