EDI是什麼？較API，有什麼不同？

EDI （Electronic Data Interchange），即電子資料交換，旨在實現兩個企業之間業務系統資料的交換。

比如，一家公司可以透過電子資料交換平臺，向另一家公司傳送訂單、查詢庫存、通知發貨等資訊。幫助企業整合供應鏈、降低庫存、實現精益生產。

知行之橋是中國製造的擁有自主智慧財產權的中文版EDI系統，基於知行之橋EDI系統搭建的企業級EDI解決方案，遍佈汽車、物流、電子、零售、快消品、能源化工、IT軟體服務商等行業。

EDI的迅猛發展，其影響已波及全球，

小至個體零售商，大至汽車主機廠、國際物流樞紐等，凡是需要傳輸資料，就可以用到EDI。

多數國內客戶初次接觸或是實施EDI，是為了響應國外交易夥伴要求。 隨著國內外貿易合作的深入以及大家對EDI技術的瞭解，已經逐漸由之前的被動實施變為主動推進，國內越來越多的企業主動搭建EDI系統，對接上下游交易夥伴，提升企業資料傳輸自動化水平，提高企業市場競爭力。

相比EDI，API 已耳熟能詳，國內不少企業已在供應鏈管理解決方案涉及了 API。由於國內EDI發展勢頭愈發強勁，很多企業不得不停下API的腳步開始思考：相對於傳統API的方式而言，EDI 究竟有什麼優勢呢，能夠在全球範圍內有如此的推廣成果呢？

<搬個小板凳 開始聽課啦>

API 與 EDI 各有優勢 ，API 的使用範圍更廣，功能層面上也比 EDI 更強，可以實現更精細化的功能，但技術門檻高，需要專業看法人員才能實現，這在無形中也增加了成本。EDI 為解決通用性的問題，可能損失了一些小細節，但因其標準化程度高，且技術門檻低，大大降低了開發及運維成本。

在某些特定情況下，比如企業間的資料交換，使用API 技術，這時API 就是 EDI。EDI的全稱是電子資料交換，它的出現就是為了實現企業間的資料交換。

在此應用場景下，既然API 和 EDI都是電子資料交換，那使用哪個技術，更容易且成熟度夠高呢？

先從

資料結構

開始

使用API，API的設計者一般會根據企業自身的業務邏輯涉及資料結構，在涉及資料結構時，需要開發人員與業務充分深入的溝通，完全理解業務含義，甚至要考慮未來業務擴充套件等，預測未來可能出現的變動，基於此，再去設計API的資料解耦股，對於開發人員的要求太高了，若非對供應鏈業務有足夠了解，很難一次到位，設計出完美的資料結構。

提及EDI，

EDI擁有標準化的商業文件，最常見的有X12和EDIFACT等。

X12是由美國國家標準委員會在1979年創立的認可標準委員會（ASC）X12制定的EDI報文標準，而EDIFACT則是聯合國歐洲經濟委員會（UN/ECE）為簡化貿易程式促進國際貿易活動，公佈的一套用於行政、商業和運輸業的EDI國際標準。

這些商業化標準，是國際組織結合各大型企業、各個行業產業的業務場景和邏輯，制定出的一套幾乎能夠覆蓋所有常見的業務場景、滿足絕大多數企業需求的商業規範文件。

EDI標準化商業文件擁有經典資料結構，相容所有常見業務，能夠解決行業內99%的問題，在全球範圍內通用。並且支援業務擴充套件，在擴充套件時不會影響到之前已經實現的合作伙伴。

（

那麼

問題來了？ 從0開始設計資料結構呢？ 還是使用全球經典、且通用的資料結構呢？

）

說到這裡，可能有人對 API 還有些疑問：“我對我們開發人員能力有著充分的資訊，我們已在涉及資料結構時考慮的非常全面，儘可能把資料解耦股設計的足夠完善”。

<槓精附體>

，你確定企業要白白耗費人力，財力，物力再去做這些重複的工作？

>

<

API 設計者自定義的資料結構，設計到極致，可能得到的就是類似EDI 標準化的資料結構

>

<某供應鏈專家，蘋果的兩大成功是產品和供應鏈，產品的成功是不可複製的，那就複製蘋果的供應鏈，悄悄告訴你，

蘋果也在透過EDI貫穿著上下游所有企業

>

<擁有超強IT實力的

Amazon

，同時支援API 和 EDI，但在年訂單量超過某個數字，就

必須使用EDI

。 >

<

Tesla 供應鏈

，IT實力牛逼呀，但在訂單量超過某數量的情況下，也

必須使用EDI

。>

<……>

諸如此類的例子太多，就不一一列舉並抬槓了。

繼續開始講

傳輸方式的不同

使用API，會用到http/https 傳輸協議。

作為API介面的設計者，通常需要考慮到連線安全性，例如使用哪種身份認證方式，token需要動態獲取還是永久授權等，同時還需考慮到授權管理和使用者管理。此外，設計者還需要考慮介面的併發效能，能否被足夠多的合作伙伴同時呼叫或頻繁多次呼叫。而作為API介面的呼叫者，以上提到的安全認證方式，可能各個API介面都不相同，需要大量的程式碼定製化開發；另外，若是有遇到API響應較慢，存在效能問題，介面呼叫者的體驗就會很差，還需考慮到呼叫失敗後的容錯機制和重發機制等。

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

<

API 傳輸層面的考慮，設計到極致，可能得到的就是AS2協議

>

（

那麼

問題來了？ 從0開始設計API 傳輸方式呢？ 還是直接使用AS2？

）

AS2，是Applicability Statement 2的縮寫，

旨在確保資料在網際網路能夠安全可靠地傳輸。

AS2的目的在於透過Internet安全可靠地傳輸商業文件。首先透過資料加密和數字簽名生成資料包，然後基於HTTP（或HTTPS）透過網際網路或任何TCP/IP網路進行安全可靠的資料交換；其MDN回執具有不可否認性，意味著資料接收方是無法否認收到的資料的，防抵賴。

小總結：

讓我們一起站在巨人的肩膀上，複製成功的供應鏈，推廣應用EDI技術吧！