OpenAPI，也稱為開放平台，是服務型網站常見的一種應用，在許多業務如海外倉WMS業務中，OpenAPI平台的存在就不容忽視。那麼，産品經理、尤其是不懂技術的産品經理，要怎麼參與搭建OpenAPI平台？不妨一起來看看這篇文章，或許會對你有所啟發。
一、什麼是OpenAPI平台？
OpenAPI即開放API，也稱為開放平台，是服務型網站常見的一種應用，網站的服務商将自己的網站服務封裝成一系列API（Application Programming Interface，應用程式設計接口）并搭建一個對外開放的平台提供給第三方開發者使用，它提供了一套标準的API接口，讓不同的業務系統可以通過這些接口進行互動和資料共享。這種行為就叫做開放網站的API，所開放的API就被稱作OpenAPI或者OpenAPI平台。
二、為什麼需要OpenAPI平台？
在海外倉WMS業務中，其他上遊系統可以通過OpenAPI與海外倉進行資料互動和資訊的傳遞，而不用從A系統導出資料，然後再登入海外倉的系統再手動導入進去，極大地提升了使用者的體驗。
無OpenAPI的模式
如果沒有OpenAPI的時候，使用者要将資料推送到海外倉WMS中，則需要從電商平台或者電商ERP中手動導出業務資料，然後再登入海外倉OMS，根據導入模闆去填寫業務資料，最後再導入到OMS中，再通過OMS推送到WMS中。而且WMS作業完成之後，雖然OMS可以看到最新的業務狀态，但是由于沒有對外的API，是以外部的系統并不知道最新的狀态，還需要人工手動根據OMS的最新狀态（資料）去更新電商平台或者電商ERP的狀态（資料）。
如果引入了OpenAPI之後，隻需要電商平台或者電商ERP和海外倉的OpenAPI完成了對接之後，這一切都不要手動去處理，系統可以自動完成相關的資料傳遞，包括上遊系統主動推送給海外倉和海外倉回報最新的資料給上遊系統等。
有OpenAPI的模式
三、OpenAPI和海外倉系統的互動示意圖
OpenAPI和海外倉系統的互動示意圖
在前面海外倉OMS的章節有介紹過，在海外倉WMS領域中，OMS承擔的是一個用戶端的角色，也是WMS的上遊端，是以一般來說外部系統是先通過OPenAPI這個通道觸達到OMS，然後再由OMS處理、轉化之後再推送到WMS中。幾乎很少有直接通過OpenAPI直接觸達WMS的玩法，海外倉領域中OMS和WMS一般都是配套出現的，很多業務邏輯都挂在OMS層面，當然如果需要特殊定制讓OpenAPI的資料直接推送到WMS層也不是不可以，國内倉的玩法就是這樣做的，稍後我們會進行介紹。
要注意的是，文中提到的OpenAPI平台是指海外倉作為提供方去建設的平台，通俗點可以了解為是上遊系統去接入海外倉WMS，而不是海外倉WMS去接入上遊系統。是以，嚴格來說電商平台并不是通過OpenAPI去接入海外倉OMS的，而是海外倉OMS通過電商平台的OpenAPI去接入電商平台，這個模式和電商ERP接入海外倉OMS是不太一樣的，剛好相反。
對于國内倉WMS來說，由于各家的倉儲系統不太一樣，發展曆程也比較悠久，很多國内倉都沒有對應的OMS，而且京東，淘寶都分别做了相關的“業務系統标準化對接平台”，例如阿裡的奇門，京東的虎符等，是以在國内電商領域，電商ERP會接入奇門，而國内倉也會接入奇門，大多數場景下就不需要倉庫WMS單獨去提供額外的OpenAPI去給ERP接入了，除非是一些耦合性比較高的特殊需求。
阿裡奇門的作用說明
随着電子商務發展，商家所使用到的各類軟體越來越多，各個軟體之間沒有互相打通，形成一個個資訊孤島，給商家的使用帶來種種不便，商家要求各個系統之間的對接需求已經越來越迫切。
目前在行業内已經有部分系統直接由服務商之間完成了系統軟體的對接，但是由于沒有統一的接入标準，導緻接入較混亂，對接接口的版本也參差不齊，往往這樣的系統對接不具有可複制性，多個系統之間的對接，需要多次開發，給商家的使用和功能疊代更新帶來了諸多的不便，同時也給服務商帶來額外的維護、開發成本。
為了滿足商家需求，讓商家能夠突破各個業務系統之間的資訊孤島，提升商家在各個系統之間的操作效率，解決各個系統之間标準化對接的痛點，我們推出了奇門項目。
奇門項目一期支援ERP、WMS 之間的系統标準化對接，通過建構 ERP、 WMS 系統之間标準通信協定來實作不同系統之間的打通。對商家來說，省去了更換系統軟體所帶來的額外開發成本。對 ISV 來說，省去了與多家ERP、 WMS系統對接難的問題，ERP通過一次對接奇門項目，打通與所有WMS之間的通信，WMS通過一次對接奇門項目，可以适配所有ERP軟體……
四、産品經理如何去參與搭建OpenAPI
前面大概介紹了什麼是OpenAPI，為什麼需要OpenAPI，以及海外倉的OpenAPI背後是用OMS來承接相應的資料，接下來就來介紹一下，作為産品經理應該怎麼參與搭建OpenAPI。
很多人以為，OpenAPI是技術相關的事情，應該全權交給技術去處理，自己壓根就不用管。但是這種想法是不對的，是片面的，對于OpenAPI的技術細節方面作為産品經理确實可以不用參與，但是其它方面的内容産品經理都是需要去參與的。
不要把OpenAPI當作一個技術名詞去了解，而是要把搭建OpenAPI平台作為一個需求，作為一款産品去對待。去分析它的商業目标是什麼，使用者群體是誰，解決了什麼問題，創造了什麼價值。細化到具體的産品設計方案就是有多少套系統，有多少業務場景，有多少功能子產品，這些和做一款資訊化系統并無二緻。
1. OpenAPI平台有哪些内容需要搭建？
如果是搭建一個OpenAPI平台，一般來說會有兩個端，分别的：
開放平台端，也可以稱之為使用者端，使用者是指需要接入OpenAPI的開發者們，他們需要在OpenAPI平台上檢視API接口文檔，檢視開放平台的接入方式，檢視自己申請的應用APP和接口調用的情況等。
API管理背景，也可以稱之為管理端，使用者是接口的提供商，例如海外倉需要對外提供開放平台的接口，那麼海外倉就需要搭建相關的API管理背景，用來釋出接口，稽核開發者的資質，還有監控一些接口的日志等。
是以，當産品經理接收到了任務需要去搭建OpenAPI平台之後，并不是說把這個事情簡單翻譯一下丢給技術人員就好了，實際上還是要把它當作一個大的項目，大的需求，去做業務的分析和梳理，做競品的調研，做使用者畫像的梳理等。起碼要搞清楚有多少個端（系統），有多少功能子產品，有幾類使用的使用者等……
2. 使用者端的搭建
一般來說開放平台的使用者端會分成這麼幾個部分：
其中API文檔和接入指南一般都是直接對外開放的，通路相關URL就可以直接通路，不會做權限的控制。
Shopee開放平台
谷倉開放平台
而控制中心/工作台則需要注冊成為了開發者，登入賬号和密碼後才可以通路，裡面一般就是包含了自己的個人資訊，接入的APP，還有一些接口調用日志，消息通知等。
4PX的開發者工作台
Shopee的開發者控制中心
3. 背景管理端的搭建
相較于使用者端來說，内部管理端的競品非常不好找，因為這個内容一般都是不對外開放的，是以這個時候産品經理往往要想好另一條路：就是多和研發人員溝通，确認一些技術需求，同時梳理出典型的業務場景，通過這些場景去設計内部的管理端功能。
例如，如果需要在使用者端需要開發者入駐，那麼開發者入駐的時候會填寫一些申請資訊，背景管理端就需要有開發者資質稽核的功能子產品。
同樣的，如果使用者端的開發者申請開通了一些APP應用，也是需要背景稽核的，那麼背景管理端也需要有對應的稽核功能子產品。
然後前台的一些API文檔和接入文檔等可能會不定期的更新，那麼背景管理端可能就需要有CMS（内容管理系統）的功能子產品，這樣才可以快速地完成修改和更新。
針對技術部分的内容，一些API的調用可能比較敏感，需要做費用的計算，調用次數的限制，日志的統計，還有異常的監控等，是以這些都需要在背景管理端去完成。
接口大師背景管理系統
4. 業務接口的梳理
通過前面3個部分内容的學習，我們知道了原來搭建一個OpenAPI平台要做這麼多事情，有這麼多内容，并不是想象中的做個“甩手掌櫃”就夠了。
如果要從0開始去搭建一個OpenAPI平台确實要做很多事情，OpenAPI搭建成本比較高，适用于有多個開發者要接入的場景，是以一般都是業務量到了一定量級之後才會去做這件事。如果目前隻有少量的使用者需要接入海外倉系統，那麼可以考慮用MVP的思路去實作，不是上來就搭建一個OpenAPI平台，而是先搭建對外的技術接口，然後整理相關的說明，用一個線上文檔或者Word等方式傳遞。
如果是以MVP的方式去傳遞，作為産品經理需要做的事情就稍微少一些，大概是下圖中的這麼一些：
産品經理怎麼輸出接口文檔
關于産品經理輸出接口文檔這件事，很多人都會有一個誤區，覺得這個東西是技術相關的内容不需要自己參與過多。但是實際上從我的個人經驗來看，如果純粹由技術輸出接口文檔，對于接入方來說非常痛苦，要麼看不懂文檔，要麼發現有些接口調不通，要麼就發現文檔閱讀體驗賊差等，對于開放平台方來說可能是偷懶了，但是接入方的産品和研發往往就很痛苦了。
而且從API文檔也可以看得出對方的研發能力，一般小規模的技術團隊或者整體能力偏差的技術團隊，輸出的API文檔都比較爛，會讓客戶産生一些不信任感，感覺不安全。
是以我都是建議産品經理要參與到開放平台或者開放接口的搭建過程中去，要和技術進行協同，你不懂技術方面的東西那就傳遞給研發去搞定，但是體驗方面的内容、業務和邏輯的表達方面的内容産品經理是需要把關的，大家都是同為一體的，應該共同為最後的傳遞結果（API功能和API文檔）承擔責任。
海外倉的OpenAPI需要開放哪些接口，這個是沒有标準的，需要結合實際的業務去選擇，這裡我把行業内做得比較好的一些友商的開放平台整理了一下，大家可以直接看他們的接口文檔，對照學習和輸出即可。
其中做得最好的應該是谷倉的開放平台，整體的體驗和邏輯說明都很優秀，值得反複看看。
https://open.goodcang.com/（重點推薦）
https://open.4px.com/apiInfo/api
https://developer.winit.com.cn/
五、API對接方面的學習和提升
OpenAPI開放平台這個項目說大也大，說小也小，和業務需求有直接的關系，但是考慮到後續大家肯定還是會有機會經曆這一塊的，是以我整理了相關的學習資料和參考資料在文末，等後續要做這一塊業務的時候再翻出來查閱即可。
1. OpenAPI平台
https://open.weixin.qq.com/
https://open.shopee.com/
https://open.lazada.com/
https://partner.tiktokshop.com/doc/page/63fd7444715d622a338c5097
2. 接口API的一些知識
https://juejin.cn/post/6987377856447774734
https://www.ruanyifeng.com/blog/2014/05/restful_api.html
https://www.ruanyifeng.com/blog/2019/04/oauth_design.html
http://www.yesx2.com/
https://www.imooc.com/learn/68/
3. 接口調試工具
https://www.bilibili.com/video/BV1ae4y1y7bf/?share_source=copy_web&vd_source=52af3a6250261fa8c6e13c736f8e3884
專欄作家
我叫維他命（Vitamin），微信公衆号：PM維他命。前PHPer，做過線上教育類産品，也做過4年多的跨境倉儲物流方向的産品，目前是一位外貿SaaS領域的供應鍊産品經理。主要專注于WMS/OMS/TMS/BMS/ERP等領域，分享供應鍊相關的産品知識。
本文原創釋出于人人都是産品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于 CC0 協定。
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。