API VS EDI

近年來，由于EDI在國内發展勢頭愈發強勁，大多數企業IT事業部都接觸到了EDI，在了解的過程中，經常會有開發人員提出疑問，相對于傳統API的方式而言，EDI究竟有什麼優勢，能夠在全球範圍内的推廣呢？

總的來說，API和EDI各有優劣，API的使用範圍更廣，功能層面上也比EDI更強，可以實作更精細化的功能，但技術門檻更高，需要專業開發人員才能實作，這在無形中也增加了成本。EDI則可以看做是API的某種具體實作，為了通用可能損失了一些細節，但其标準化的程度更高，且技術門檻低，隻需要普通IT和業務人員即可實作，成本更低。

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

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

資料結構

API方式中，一般是API的設計者根據企業自身的業務邏輯設計出的資料結構，在設計資料結構時，IT人員和業務人員需要進行充分深入的溝通，完全了解到業務含義，甚至在目前企業使用的業務邏輯上進行長遠考慮，預測未來可能出現的變動，基于此，再去設計API的資料結構，這對于開發人員的業務能力要求就非常高了，若非對供應鍊業務足夠了解，很難一次到位，制定出完美的規範标準。企業作為API的設計方，在和合作夥伴使用API方式內建時，若是在雙方關系中不夠強勢，可能還需要根據合作夥伴的需求，調整API的資料結構。我們以發貨時包裝的業務場景為例：

在需求溝通初始，開發人員和業務人員一起梳理了内部的業務邏輯，得出結論：發貨時隻會有散箱，将來肯定也不會用到托盤。但之後由于企業内部業務擴充，在包裝的時候需要用到托盤了，此時要修改API的資料格式就會變得尤為困難，一方面，開發工作量顯著增加，另一方面，之前已經對接完成的合作夥伴，他們的程式設計也需要進行改變，然後雙方重新啟動業務測試，這無疑加大了對接雙方的工作量。

而作為API的調用方，若是原始API接口資料格式做了變動，改動範圍如果隻是字段的增加的話，可能影響不會太大，但若删減字段，或者資料結構做了調整，那麼可能程式的處理邏輯也需要随之改變，甚至需要重新開發。面對某些不太靠譜的API接口設計方，接口調用方可能真的有苦難言。退一步來說，即使API接口設計方非常靠譜，在這裡悄悄說一句：亞馬遜的API接口近期已經從V2更新到V3啦~

而對于EDI而言，EDI擁有标準化的商業文檔，最常見的有X12和EDIFACT等。X12是由美國國家标準委員會在1979年創立的認可标準委員會（ASC）X12制定的EDI封包标準，而EDIFACT則是聯合國歐洲經濟委員會（UN/ECE）為簡化貿易程式促進國際貿易活動，公布的一套用于行政、商業和運輸業的EDI國際标準。這些商業化标準，是國際組織結合各大型企業、各個行業産業的業務場景和邏輯，制定出的一套幾乎能夠覆寫所有常見的業務場景、滿足絕大多數企業需求的商業規範文檔。EDI标準化商業文檔擁有經典資料結構，相容所有常見業務，能夠解決行業内99%的問題，在全球範圍内通用。并且支援業務擴充，在擴充時不會影響到之前已經實作的合作夥伴。

當然，對于非EDI專業人員來說，可能EDI唯一的問題在于對EDI商業規範标準的了解了，因為是全球通用的商業文檔，是以可讀性不是很高，過程較難梳理。不過，對于IT人員來說，絕不會比學習一門新的開發語言要難，而且舉一反三，隻要成功完成一兩個EDI的對接，後續就都不是問題了。

說到這裡，可能有人對API還有些疑問：“我對我們的IT人員能力有着充分的信心，我們可以在設計資料結構時就考慮的非常全面，盡可能的把資料結構設計的足夠完善”。想說的是，EDI商業化文檔是國際組織經過幾十年的探索和實踐，應用于數以億計的企業使用者，并且在不斷的進行完善後得到的一套文檔結構和标準，在已經有這種模式化的商業文檔的前提下，企業沒有必要浪費太多的人力物力财力再去做重複的工作，自定義API設計到極緻，可能得到的也就是EDI了。

資料格式

API自定義格式時，可以任意選擇如CSV、XML、JSON等常見資料格式。EDI商業文檔則是全球統一标準格式，選擇性很少，标準化很高。

資料格式僅僅是相同資料的不同表現形式，沒有優劣可言。但從另一方面來說，選擇多樣化，可能也會産生更多的溝通成本，進而出現更多問題。

資料傳輸方式

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

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

以對接沃爾瑪為例，沃爾瑪提供了兩種對接方案，分别是API和EDI。供應商在向沃爾瑪請求擷取訂單時，如果選擇API調用，就需要定時向沃爾瑪發送請求，建立連接配接，主動擷取訂單；而如果使用EDI，沃爾瑪産生訂單後會主動推送至客戶系統，無需重複請求。在訂單量較大的情況下，API調用還有可能存在并發問題，這也是為什麼沃爾瑪要求供應商，如果一年的訂單量預計會超過15,000單時，必須要使用EDI來完成對接。

進一步來說，API和EDI也不是非此即彼的相對關系，企業可以将其融合，在标準化的同時，實作更貼近自己内部的業務，API和EDI，何不兩者兼得？