EDI還是API，企業(yè)應該如何選擇？
2021-12-13 17:49:14

近年來，由于EDI在國內(nèi)發(fā)展勢頭愈發(fā)強勁，大多數(shù)企業(yè)IT事業(yè)部都接觸到了EDI，在了解的過程中，經(jīng)常會有開發(fā)人員提出疑問，相對于傳統(tǒng)API的方式而言，EDI究竟有什么優(yōu)勢，能夠在全球范圍內(nèi)的推廣呢？

總的來說，API和EDI各有優(yōu)劣，API的使用范圍更廣，功能層面上也比EDI更強，可以實現(xiàn)更精細化的功能，但技術(shù)門檻更高，需要專業(yè)開發(fā)人員才能實現(xiàn)，這在無形中也增加了成本。EDI則可以看做是API的某種具體實現(xiàn)，為了通用可能損失了一些細節(jié)，但其標準化的程度更高，且技術(shù)門檻低，只需要普通IT和業(yè)務(wù)人員即可實現(xiàn)，成本更低。

為了大家能夠清晰直觀的進行對比，小知特意做了表格：

我們從以下幾個點一起來看看:

數(shù)據(jù)結(jié)構(gòu)

API方式中，一般是API的設(shè)計者根據(jù)企業(yè)自身的業(yè)務(wù)邏輯設(shè)計出的數(shù)據(jù)結(jié)構(gòu)，在設(shè)計數(shù)據(jù)結(jié)構(gòu)時，IT人員和業(yè)務(wù)人員需要進行充分深入的溝通，完全理解到業(yè)務(wù)含義，甚至在當前企業(yè)使用的業(yè)務(wù)邏輯上進行長遠考慮，預測未來可能出現(xiàn)的變動，基于此，再去設(shè)計API的數(shù)據(jù)結(jié)構(gòu)，這對于開發(fā)人員的業(yè)務(wù)能力要求就非常高了，若非對供應鏈業(yè)務(wù)足夠了解，很難一次到位，制定出完美的規(guī)范標準。企業(yè)作為API的設(shè)計方，在和合作伙伴使用API方式集成時，若是在雙方關(guān)系中不夠強勢，可能還需要根據(jù)合作伙伴的需求，調(diào)整API的數(shù)據(jù)結(jié)構(gòu)。我們以發(fā)貨時包裝的業(yè)務(wù)場景為例：

在需求溝通初始，開發(fā)人員和業(yè)務(wù)人員一起梳理了內(nèi)部的業(yè)務(wù)邏輯，得出結(jié)論：發(fā)貨時只會有散箱，將來肯定也不會用到托盤。但之后由于企業(yè)內(nèi)部業(yè)務(wù)擴展，在包裝的時候需要用到托盤了，此時要修改API的數(shù)據(jù)格式就會變得尤為困難，一方面，開發(fā)工作量顯著增加，另一方面，之前已經(jīng)對接完成的合作伙伴，他們的程序設(shè)計也需要進行改變，然后雙方重新啟動業(yè)務(wù)測試，這無疑加大了對接雙方的工作量。

而作為API的調(diào)用方，若是原始API接口數(shù)據(jù)格式做了變動，改動范圍如果只是字段的增加的話，可能影響不會太大，但若刪減字段，或者數(shù)據(jù)結(jié)構(gòu)做了調(diào)整，那么可能程序的處理邏輯也需要隨之改變，甚至需要重新開發(fā)。面對某些不太靠譜的API接口設(shè)計方，接口調(diào)用方可能真的有苦難言。退一步來說，即使API接口設(shè)計方非?？孔V，小知在這里悄悄說一句：亞馬遜的API接口近期已經(jīng)從V2升級到V3啦~

而對于EDI而言，EDI擁有標準化的商業(yè)文檔，最常見的有X12和EDIFACT等。X12是由美國國家標準委員會在1979年創(chuàng)立的認可標準委員會（ASC）X12制定的EDI報文標準，而EDIFACT則是聯(lián)合國歐洲經(jīng)濟委員會（UN/ECE）為簡化貿(mào)易程序促進國際貿(mào)易活動，公布的一套用于行政、商業(yè)和運輸業(yè)的EDI國際標準。這些商業(yè)化標準，是國際組織結(jié)合各大型企業(yè)、各個行業(yè)產(chǎn)業(yè)的業(yè)務(wù)場景和邏輯，制定出的一套幾乎能夠覆蓋所有常見的業(yè)務(wù)場景、滿足絕大多數(shù)企業(yè)需求的商業(yè)規(guī)范文檔。EDI標準化商業(yè)文檔擁有經(jīng)典數(shù)據(jù)結(jié)構(gòu)，兼容所有常見業(yè)務(wù)，能夠解決行業(yè)內(nèi)99%的問題，在全球范圍內(nèi)通用。并且支持業(yè)務(wù)擴展，在擴展時不會影響到之前已經(jīng)實現(xiàn)的合作伙伴。

當然，對于非EDI專業(yè)人員來說，可能EDI唯一的問題在于對EDI商業(yè)規(guī)范標準的理解了，因為是全球通用的商業(yè)文檔，所以可讀性不是很高，過程較難梳理。不過，對于IT人員來說，絕不會比學習一門新的開發(fā)語言要難，而且舉一反三，只要成功完成一兩個EDI的對接，后續(xù)就都不是問題了。

說到這里，可能有人對API還有些疑問：“我對我們的IT人員能力有著充分的信心，我們可以在設(shè)計數(shù)據(jù)結(jié)構(gòu)時就考慮的非常全面，盡可能的把數(shù)據(jù)結(jié)構(gòu)設(shè)計的足夠完善”。小知想說的是，EDI商業(yè)化文檔是國際組織經(jīng)過幾十年的探索和實踐，應用于數(shù)以億計的企業(yè)用戶，并且在不斷的進行完善后得到的一套文檔結(jié)構(gòu)和標準，在已經(jīng)有這種模式化的商業(yè)文檔的前提下，企業(yè)沒有必要浪費太多的人力物力財力再去做重復的工作，自定義API設(shè)計到極致，可能得到的也就是EDI了。

數(shù)據(jù)格式

API自定義格式時，可以任意選擇如CSV、XML、JSON等常見數(shù)據(jù)格式。EDI商業(yè)文檔則是全球統(tǒng)一標準格式，選擇性很少，標準化很高。

數(shù)據(jù)格式僅僅是相同數(shù)據(jù)的不同表現(xiàn)形式，沒有優(yōu)劣可言。但從另一方面來說，選擇多樣化，可能也會產(chǎn)生更多的溝通成本，從而出現(xiàn)更多問題。

數(shù)據(jù)傳輸方式

使用API調(diào)用作為傳輸方式時，會用到http/https傳輸協(xié)議。作為API接口的設(shè)計者，通常需要考慮到連接安全性，例如使用哪種身份認證方式，token需要動態(tài)獲取還是永久授權(quán)等，同時還需考慮到授權(quán)管理和用戶管理。此外，設(shè)計者還需要考慮接口的并發(fā)性能，能否被足夠多的合作伙伴同時調(diào)用或頻繁多次調(diào)用。而作為API接口的調(diào)用者，以上提到的安全認證方式，可能各個API接口都不相同，需要大量的代碼定制化開發(fā)；另外，若是有遇到API響應較慢，存在性能問題，接口調(diào)用者的體驗就會很差，還需考慮到調(diào)用失敗后的容錯機制和重發(fā)機制等。

使用EDI傳輸，最常使用的是AS2傳輸協(xié)議和OFTP2傳輸協(xié)議，這些傳輸協(xié)議都需要通過國際機構(gòu)的互操作性認證，其中包含了許多對于異常的格式化處理，例如斷點續(xù)傳、發(fā)送失敗自動重發(fā)、使用回執(zhí)確保不可抵賴、第三方CA機構(gòu)頒發(fā)的證書用于簽名加密的安全保障等，所有的要求是否啟用僅需要簡單的勾選配置即可，無需任何代碼實現(xiàn)。

以對接沃爾瑪為例，沃爾瑪提供了兩種對接方案，分別是API和EDI。供應商在向沃爾瑪請求獲取訂單時，如果選擇API調(diào)用，就需要定時向沃爾瑪發(fā)送請求，建立連接，主動獲取訂單；而如果使用EDI，沃爾瑪產(chǎn)生訂單后會主動推送至客戶系統(tǒng)，無需重復請求。在訂單量較大的情況下，API調(diào)用還有可能存在并發(fā)問題，這也是為什么沃爾瑪要求供應商，如果一年的訂單量預計會超過15,000單時，必須要使用EDI來完成對接。

進一步來說，API和EDI也不是非此即彼的相對關(guān)系，企業(yè)可以將其融合，在標準化的同時，實現(xiàn)更貼近自己內(nèi)部的業(yè)務(wù)，API和EDI，何不兩者兼得？

更多EDI相關(guān)知識，請參考文章：???????EDI白皮書??

注：文案部分圖片及內(nèi)容來源于網(wǎng)絡(luò)，版權(quán)歸原創(chuàng)作者所有，如有侵犯到您的權(quán)益，請您聯(lián)系我進行刪除，給您帶來困擾，深感抱歉。

了解更多EDI相關(guān)信息，歡迎交流。

EDI 顧問Iris

如需轉(zhuǎn)載或者了解更多EDI 相關(guān)信息，歡迎聯(lián)系：137-2065-8862（微信同號）