决定在供应链管理上使用API之前请先阅读下这篇文章 省钱 省心 省力

EDI已广泛应用于汽车、物流、零售、医药、电子、化工等行业，EDI的迅猛发展，其影响已波及全球。小至个体零售商，大至汽车主机厂、国际物流枢纽等，凡是需要传输数据，就可以用到EDI。多数国内客户初次接触或是实施EDI，是为了响应国外交易伙伴要求。

随着国内外贸易合作的深入以及大家对EDI技术的了解，已经逐渐由之前的被动实施变为主动推进，国内越来越多的企业主动搭建EDI系统，对接上下游交易伙伴，提升企业数据传输自动化水平，提高企业市场竞争力。相比EDI，API 已耳熟能详，国内不少企业已在供应链管理解决方案涉及了 API。无论您是 API 接口的设计者，还是API 接口的调用者，请花三分钟时间详细阅读这篇文章。

在某种特定情况下，比如通过API 实现 B2B 之间的数据交换，这时 API也就是EDI了。 EDI全称是电子数据交换，旨在实现两个企业之间业务系统数据的交换。

无论通过什么方式完成企业间的数据交换，都可以被称为EDI。一般提及到EDI，默许是使用统一的传输协议，比如AS2，传输国际组织定义的商业文档。

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，何不两者兼得？