起點課堂會員權益
職業(yè)體系課特權
線下行業(yè)大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識 產(chǎn)品經(jīng)理對接外部API，4個案例避坑指南?。ǜ韶浭詹兀?/h2>
今天，我們將跟隨一位資深產(chǎn)品經(jīng)理的視角，深入探討在對接外部API和SDK時常見的問題和挑戰(zhàn)，并通過4個實際案例，為你提供寶貴的避坑指南。
在IT服務外包流傳一句話：做你最擅長的(核心競爭力)，其余的外包！
分工協(xié)作，已經(jīng)成為一種不可逆轉(zhuǎn)的趨勢。
把“面向?qū)ο蟆钡乃枷?、“不重復造輪子”的古訓，和生態(tài)協(xié)作的服務理念碰撞一起，似乎就很好地解釋了對接API（或SDK）的重要和頻繁性！通常而言，系統(tǒng)對接的場景主要但不限于如下：
- 前端和后端本身無時不刻的數(shù)據(jù)互動。
- 公司的各個系統(tǒng)之間的信息共享。
- 與第三方業(yè)務平臺的對接，比如入駐第三方銷售平臺亞馬遜之后，要從亞馬遜平臺獲取訂單數(shù)據(jù)。
- 調(diào)用公共服務的公共插件，如公安系統(tǒng)。
上述場景，要說最難的是“與第三方業(yè)務平臺的對接”。
因為人家也是做生意的，寫代碼的都是技術打工仔，誰也不認識誰……
這時候，坑就變得常見了！
01 API夠清晰，可以0溝通嗎？
曾經(jīng)為一個地產(chǎn)老板搞過一個音視頻類App項目。
引用的喬布斯的話：
創(chuàng)新根本就不是重做新的事情，而是把既有的東西重新組合起來。
而我們做的這個App，就是“重新組合”了Soul的音視頻匹配+陌陌的附近人+花椒的直播+抖音的小視頻+帶貨，（當然后來沒運營成功）。
要說的重點不是它的“創(chuàng)新”，而是前后一共就兩個月就灰度發(fā)布了，其實是蠻快的。
因為核心的運算都是用的第三方SDK。如向芯的美顏、騰訊的鑒黃和視頻拍攝、七牛的直播……
那是音視頻的黃金期，服務商也有的挑，可以貨比三家，每一種方案也不同收費。
開發(fā)的過程中，對這些SDK也是邊做，邊對比，邊讓產(chǎn)品拿主意。好在測試環(huán)境更換的成本低。
這個案例中雖然沒有客服協(xié)調(diào)我們的對接進度，但是人家的接口質(zhì)量OK，且選擇空間大，所以最后組裝起來的App測試順利！
02 SDK服務化，提升舒適感！
曾經(jīng)還主導過一個項目，是做電子合同。
對接的是法大大的SDK——這個結(jié)合了云服務+區(qū)塊鏈等核心底層技術的SDK，提供了完善的認證外鏈、簽章鏈接。
這家的客服（或商務）服務就比前面的較好！
作為對接方客戶，自己做個簡單的觸發(fā)入口即可，其余的界面全部都可以用法大大自己的外鏈面完成業(yè)務。
所以是相當成熟的一次對接，也很順利，也好理解。
最主要的是它的客服和實施工程師都很nice，不管是業(yè)務還是技術都對接的很到位！
所以法大大的口碑一直不錯，真正“面向服務”的里面做商業(yè)服務。給對接帶來了安全感！
03 ?SDK背后可能是個“黑盒子”
過往做的最多的是商品交易類中臺。所以對接更多的還是各大渠道平臺，或者ERP系統(tǒng)。
做跨境電商的時候，印象國外的幾個平臺比較變態(tài)的是Lazada、JUMIA。
為啥呢？我記得它的訂單維度、商品維度和一般的平臺不一樣，支付業(yè)務復雜導致訂單與付款單等的對應關系不齊。
退貨流程又復雜又維度對不上。導致你要做它的自動創(chuàng)建RMA單據(jù)很麻煩，容易出錯。最主要是有了問題都難溝通。
后來開始對接國內(nèi)的平臺了，就是熟悉的美團、京東健康。這都好說，但是也會遇到坑。
比如一個平臺“藥某某”，居然離開API渠道就不能玩（雖然模式可選擇，但是對絕大多數(shù)用戶就是沒得選擇）。
這導致的就是，它成了一個沒有樓梯的碉堡。你在里面沒糧食。你要吃喝，要拉撒，都要通過一根繩子（接口）進行傳輸。
對方也是給個OPEN API就沒有商務了（這讓我想到法大大的商務和實施服務都很體貼）。也不給測試環(huán)境的用戶操作頁面。也不說有哪些坑。
于是我們從MVP角度出發(fā)，先對接了新增商品，結(jié)果發(fā)現(xiàn)一次只能增加1個商品，每分鐘最多30個商品。接口要推送20來個必傳字段，還是不常用的。
那就像是說，你送飯的時候，幾百人在上面喊著餓，可是你一次只能遞上去一碗，遞不完，你還不能走。
對方說飯里要蔥花，不要香草，你還要打回來重新加工后再傳上去。
終于搞了數(shù)據(jù)上去，結(jié)果該平臺自己的頁面連刪除都刪不掉（之前為啥沒發(fā)現(xiàn)功能問題，因為沒數(shù)據(jù)的時候，頁面功能都顯示不全）。于是就要新增一個刪除接口。
又發(fā)現(xiàn)價格也不能在平臺改，又要加個修改價格的接口……
這就是阿甘說的：
Life was like a box of chocolates,you never know what you’re gonna get！
04 接上了，也被套住了
做O2O電商中臺的時候，中臺是按照“銷售平臺+門店+商品”維度構建數(shù)據(jù)的。
一個連鎖店，多的可以達到9千家門店（資本的加持下，收購比收割都快）。
而常用商品品種3000，你算算，就算只在一個平臺銷售，那也是2700萬條基礎數(shù)據(jù)（算對了吧）。
然后這些數(shù)據(jù)要通過中臺，盡快地增量同步庫存變化量到銷售平臺。
于是出現(xiàn)了可想而知的問題：同步池中的數(shù)據(jù)量會很大；經(jīng)常量丟數(shù)據(jù)導致同步失敗；用戶等待時間過長。
究其原因：
- 觸發(fā)次數(shù)多
- 數(shù)量大，占用線程擠滿，資源不夠。
- 銷售平臺限流，提交過多的數(shù)據(jù)就被限制不執(zhí)行。若平臺不反饋失敗數(shù)據(jù)，那么失敗后我們也不知道遺漏了哪些。
幾次事故之后，最終除了這樣的解決方案：
- 第一：減少來源，重點是前端的操作入口分離，并限制操作頻率。
- 第二：對待處理數(shù)據(jù)進行清洗，去重、對比、改變存儲方式等。
- 第三：增加失敗補償機制和日志。
具體的思路模型：
- 敲定場景：場景是無法無視的，場景確定，是做正確事的前提。當確定必須解決這個問題的時候，就可以靜下心找方案。
- 控制入口：因為數(shù)據(jù)量大，所以先從來源上做增益。
- 清洗數(shù)據(jù)：同樣是為了擺脫無效數(shù)據(jù)，盡可能降低冗余。
- 處理并發(fā)：通過對比、時間戳等，濾掉無效數(shù)據(jù)。
- 輸出日志：讓用戶有跡可循，自行追溯。
但是實際上還是個開放性的結(jié)局，因為總會出現(xiàn)爆發(fā)式?jīng)_擊，導致系統(tǒng)扛不??！
總結(jié)
好的API對開發(fā)者來說是一種向?qū)?，他也是一種優(yōu)雅的服務。開發(fā)者通過URL中的每個目錄節(jié)點都可以了解到該接口的大體屬性。但是壞的對接，一坑更比一坑坑。
第一坑：協(xié)調(diào)溝通太難
做接口本身并不難，難的就是前期的溝通和做接口方案。
因為每個軟件廠商的產(chǎn)品標準都不一樣，要對接哪個軟件系統(tǒng)，就必須找到對應的軟件廠商，涉及的軟件廠家越多，要溝通的對象就越多，如果是所謂的大數(shù)據(jù)平臺的建設，需要匯集各個系統(tǒng)的建設，少則幾家，多則幾十家，往往前期協(xié)調(diào)溝通耗費大量的時間和精力。
第二坑：接口限制太高
不論是BS還是CS架構的軟件系統(tǒng)，每個軟件系統(tǒng)都處于廠家的勢力范圍。為了自身的安全，往往對非VIP客戶各種瀏覽限制。這樣就算接上了，也各種癱瘓。
數(shù)據(jù)掌握在軟件廠商手里，是否開放接口、以什么方式提供接口、一個接口是幾千、幾萬、十幾萬……決策權都在于軟件廠商。
第三坑：接口信息不規(guī)范或自己都沒做好
正如有同事說的“T迅”的代碼也沒好到哪里去”。有很多大廠的API你也會覺得像是實習生寫的。
返回的錯誤信息，連轉(zhuǎn)義都不給，技術工單沒人理。只能忍著，被自己的用戶吐槽。
第四坑：業(yè)務或數(shù)據(jù)維度不協(xié)調(diào)
別人是按規(guī)格對應銷售的，你這邊是按SPU銷售的；別人是按自己的標庫維護的資料，并且有自己的“條形碼”生成規(guī)則，而你沒有；別人是存在十二種優(yōu)惠類型的，而你沒有……直呼變態(tài)！
本文由人人都是產(chǎn)品經(jīng)理作者【產(chǎn)品參趙】，微信公眾號：【產(chǎn)品參趙】，原創(chuàng)/授權 發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。
題圖來自Unsplash，基于 CC0 協(xié)議。
更多精彩內(nèi)容，請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
今天，我們將跟隨一位資深產(chǎn)品經(jīng)理的視角，深入探討在對接外部API和SDK時常見的問題和挑戰(zhàn)，并通過4個實際案例，為你提供寶貴的避坑指南。
在IT服務外包流傳一句話：做你最擅長的(核心競爭力)，其余的外包！
分工協(xié)作，已經(jīng)成為一種不可逆轉(zhuǎn)的趨勢。
把“面向?qū)ο蟆钡乃枷?、“不重復造輪子”的古訓，和生態(tài)協(xié)作的服務理念碰撞一起，似乎就很好地解釋了對接API（或SDK）的重要和頻繁性！通常而言，系統(tǒng)對接的場景主要但不限于如下：
- 前端和后端本身無時不刻的數(shù)據(jù)互動。
- 公司的各個系統(tǒng)之間的信息共享。
- 與第三方業(yè)務平臺的對接，比如入駐第三方銷售平臺亞馬遜之后，要從亞馬遜平臺獲取訂單數(shù)據(jù)。
- 調(diào)用公共服務的公共插件，如公安系統(tǒng)。
上述場景，要說最難的是“與第三方業(yè)務平臺的對接”。
因為人家也是做生意的，寫代碼的都是技術打工仔，誰也不認識誰……
這時候，坑就變得常見了！
01 API夠清晰，可以0溝通嗎？
曾經(jīng)為一個地產(chǎn)老板搞過一個音視頻類App項目。
引用的喬布斯的話：
創(chuàng)新根本就不是重做新的事情，而是把既有的東西重新組合起來。
而我們做的這個App，就是“重新組合”了Soul的音視頻匹配+陌陌的附近人+花椒的直播+抖音的小視頻+帶貨，（當然后來沒運營成功）。
要說的重點不是它的“創(chuàng)新”，而是前后一共就兩個月就灰度發(fā)布了，其實是蠻快的。
因為核心的運算都是用的第三方SDK。如向芯的美顏、騰訊的鑒黃和視頻拍攝、七牛的直播……
那是音視頻的黃金期，服務商也有的挑，可以貨比三家，每一種方案也不同收費。
開發(fā)的過程中，對這些SDK也是邊做，邊對比，邊讓產(chǎn)品拿主意。好在測試環(huán)境更換的成本低。
這個案例中雖然沒有客服協(xié)調(diào)我們的對接進度，但是人家的接口質(zhì)量OK，且選擇空間大，所以最后組裝起來的App測試順利！
02 SDK服務化，提升舒適感！
曾經(jīng)還主導過一個項目，是做電子合同。
對接的是法大大的SDK——這個結(jié)合了云服務+區(qū)塊鏈等核心底層技術的SDK，提供了完善的認證外鏈、簽章鏈接。
這家的客服（或商務）服務就比前面的較好！
作為對接方客戶，自己做個簡單的觸發(fā)入口即可，其余的界面全部都可以用法大大自己的外鏈面完成業(yè)務。
所以是相當成熟的一次對接，也很順利，也好理解。
最主要的是它的客服和實施工程師都很nice，不管是業(yè)務還是技術都對接的很到位！
所以法大大的口碑一直不錯，真正“面向服務”的里面做商業(yè)服務。給對接帶來了安全感！
03 ?SDK背后可能是個“黑盒子”
過往做的最多的是商品交易類中臺。所以對接更多的還是各大渠道平臺，或者ERP系統(tǒng)。
做跨境電商的時候，印象國外的幾個平臺比較變態(tài)的是Lazada、JUMIA。
為啥呢？我記得它的訂單維度、商品維度和一般的平臺不一樣，支付業(yè)務復雜導致訂單與付款單等的對應關系不齊。
退貨流程又復雜又維度對不上。導致你要做它的自動創(chuàng)建RMA單據(jù)很麻煩，容易出錯。最主要是有了問題都難溝通。
后來開始對接國內(nèi)的平臺了，就是熟悉的美團、京東健康。這都好說，但是也會遇到坑。
比如一個平臺“藥某某”，居然離開API渠道就不能玩（雖然模式可選擇，但是對絕大多數(shù)用戶就是沒得選擇）。
這導致的就是，它成了一個沒有樓梯的碉堡。你在里面沒糧食。你要吃喝，要拉撒，都要通過一根繩子（接口）進行傳輸。
對方也是給個OPEN API就沒有商務了（這讓我想到法大大的商務和實施服務都很體貼）。也不給測試環(huán)境的用戶操作頁面。也不說有哪些坑。
于是我們從MVP角度出發(fā)，先對接了新增商品，結(jié)果發(fā)現(xiàn)一次只能增加1個商品，每分鐘最多30個商品。接口要推送20來個必傳字段，還是不常用的。
那就像是說，你送飯的時候，幾百人在上面喊著餓，可是你一次只能遞上去一碗，遞不完，你還不能走。
對方說飯里要蔥花，不要香草，你還要打回來重新加工后再傳上去。
終于搞了數(shù)據(jù)上去，結(jié)果該平臺自己的頁面連刪除都刪不掉（之前為啥沒發(fā)現(xiàn)功能問題，因為沒數(shù)據(jù)的時候，頁面功能都顯示不全）。于是就要新增一個刪除接口。
又發(fā)現(xiàn)價格也不能在平臺改，又要加個修改價格的接口……
這就是阿甘說的：
Life was like a box of chocolates,you never know what you’re gonna get！
04 接上了，也被套住了
做O2O電商中臺的時候，中臺是按照“銷售平臺+門店+商品”維度構建數(shù)據(jù)的。
一個連鎖店，多的可以達到9千家門店（資本的加持下，收購比收割都快）。
而常用商品品種3000，你算算，就算只在一個平臺銷售，那也是2700萬條基礎數(shù)據(jù)（算對了吧）。
然后這些數(shù)據(jù)要通過中臺，盡快地增量同步庫存變化量到銷售平臺。
于是出現(xiàn)了可想而知的問題：同步池中的數(shù)據(jù)量會很大；經(jīng)常量丟數(shù)據(jù)導致同步失敗；用戶等待時間過長。
究其原因：
- 觸發(fā)次數(shù)多
- 數(shù)量大，占用線程擠滿，資源不夠。
- 銷售平臺限流，提交過多的數(shù)據(jù)就被限制不執(zhí)行。若平臺不反饋失敗數(shù)據(jù)，那么失敗后我們也不知道遺漏了哪些。
幾次事故之后，最終除了這樣的解決方案：
- 第一：減少來源，重點是前端的操作入口分離，并限制操作頻率。
- 第二：對待處理數(shù)據(jù)進行清洗，去重、對比、改變存儲方式等。
- 第三：增加失敗補償機制和日志。
具體的思路模型：
- 敲定場景：場景是無法無視的，場景確定，是做正確事的前提。當確定必須解決這個問題的時候，就可以靜下心找方案。
- 控制入口：因為數(shù)據(jù)量大，所以先從來源上做增益。
- 清洗數(shù)據(jù)：同樣是為了擺脫無效數(shù)據(jù)，盡可能降低冗余。
- 處理并發(fā)：通過對比、時間戳等，濾掉無效數(shù)據(jù)。
- 輸出日志：讓用戶有跡可循，自行追溯。
但是實際上還是個開放性的結(jié)局，因為總會出現(xiàn)爆發(fā)式?jīng)_擊，導致系統(tǒng)扛不??！
總結(jié)
好的API對開發(fā)者來說是一種向?qū)?，他也是一種優(yōu)雅的服務。開發(fā)者通過URL中的每個目錄節(jié)點都可以了解到該接口的大體屬性。但是壞的對接，一坑更比一坑坑。
第一坑：協(xié)調(diào)溝通太難
做接口本身并不難，難的就是前期的溝通和做接口方案。
因為每個軟件廠商的產(chǎn)品標準都不一樣，要對接哪個軟件系統(tǒng)，就必須找到對應的軟件廠商，涉及的軟件廠家越多，要溝通的對象就越多，如果是所謂的大數(shù)據(jù)平臺的建設，需要匯集各個系統(tǒng)的建設，少則幾家，多則幾十家，往往前期協(xié)調(diào)溝通耗費大量的時間和精力。
第二坑：接口限制太高
不論是BS還是CS架構的軟件系統(tǒng)，每個軟件系統(tǒng)都處于廠家的勢力范圍。為了自身的安全，往往對非VIP客戶各種瀏覽限制。這樣就算接上了，也各種癱瘓。
數(shù)據(jù)掌握在軟件廠商手里，是否開放接口、以什么方式提供接口、一個接口是幾千、幾萬、十幾萬……決策權都在于軟件廠商。
第三坑：接口信息不規(guī)范或自己都沒做好
正如有同事說的“T迅”的代碼也沒好到哪里去”。有很多大廠的API你也會覺得像是實習生寫的。
返回的錯誤信息，連轉(zhuǎn)義都不給，技術工單沒人理。只能忍著，被自己的用戶吐槽。
第四坑：業(yè)務或數(shù)據(jù)維度不協(xié)調(diào)
別人是按規(guī)格對應銷售的，你這邊是按SPU銷售的；別人是按自己的標庫維護的資料，并且有自己的“條形碼”生成規(guī)則，而你沒有；別人是存在十二種優(yōu)惠類型的，而你沒有……直呼變態(tài)！
本文由人人都是產(chǎn)品經(jīng)理作者【產(chǎn)品參趙】，微信公眾號：【產(chǎn)品參趙】，原創(chuàng)/授權 發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。
題圖來自Unsplash，基于 CC0 協(xié)議。
- 目前還沒評論，等你發(fā)揮！
