API vs EDI原创

大家好，我是知行软件的EDI顾问瑞。随着EDI在国内发展势头愈发强劲，大多数企业的it事业部都接触到了EDI，而相较于传统的API方式而言，企业应当如何进行选择呢？本视频将从数据结构、数据格式和数据的传输方式这三个方面来对API和EDI进行比较。首先是数据结构，API方式中一般是由API设计方根据企业自身的业务逻辑设计出数据结构。在设计时，It人员和业务人员需要进行沟通，完全理解业务含义，甚至要在当前业务逻辑上预测未来可能的变动。基于此，再去设计API数据结构可能还需要根据合作伙伴的需求进行调整。我们以发货时包装的业务场景为例，在需求沟通初始，开发人员和业务人员根据公司业务确定发货时只会有散箱包装，但之后由于企业内部业务扩展，在包装时需要用到托盘了，此时要修改API的数据格式就会变得尤为困难。一方面开发的工作量显著增加，另一方面，之前已经完成对接的合作伙伴，他们的程序设计需要进行改变，然后双方重新启动业务测试，这无疑加大了对接双方的工作量。

而作为API的调用方，若是原始的API数据格式做了变动，改动范围如果只是字段增加的话，可能影响不会太大，但如删减字段或者数据结构做了调整，那么可能程序的处理逻辑也需要随之改变，甚至需要重新开发。对于EDI而言，EDI拥有标准化的商业文档，最常见的X12和EDI等。这些商业化标准是国际组织结合各大型企业、各个行业、产业的业务场景和逻辑，制定出的一套几乎能够覆盖所有场景的业务场景。

满足绝大多数企业需求的商业规范文档。一代标准化商业文档，拥有经典数据结构，兼容常见业务，解决行业内99%的问题，且在全球范围内通用，并且支持业务扩展，在扩展时不会影响到之前已经对接的合作伙伴。当然，对于非EDI专业人员来说，可能EDI唯一的问题在于对商业规范标准的理解了。因为是全球通用的商业文档，所以可读性不是很高，过程较难梳理。在数据格式上，API自定义格式时可以任意选择，如csv X ma Jason等，常见数据格式时，EDI商业文档则是全球统一标准格式，如X12EDI等，选择性较少，标准化程度高，但数据格式仅仅是相同数据的不同表现形式。

没有优劣可言。从另一个方面来说，选择多样化可能也会产生更多的沟通成本，从而出现更多的问题。使用API调用作为数据传输方式时，会用到HTTP或HTTPS传输协议。作为API接口的设计者通常需要考虑到连接安全性，例如使用哪种身份认证方式，Token需要动态获取还是永久授权，同时还需要考虑到授权管理和用户管理。此外，设计者还需要考虑接口的并发性能，能否被足够多的合作伙伴同时调用或频繁多次调用。而作为API接口的调用者，以上提到的安全认证方式可能各个API接口都不相同，则需要大量代码的定制化开发。另外，若是遇到API相应响应较慢，存在性能问题，接口调用者的体验就会很差，所以还要考虑到调用失败后的容错机制和重发机制等。

使用EDI传输最常使用的是as two传输协议和oftpr传输协议。这些传输协议都需要通过国际机构的互操作性认证，其中包含了许多对于异常的格式化处理，例如断点续传、发送失败、自动重发、使用回执、确保不可抵赖、第三方CA机构颁发的证书、用于签名加密的安全保障等。所有的要求是否启用，只需要简单的勾选配置即可，无需任何代码实现。以对接沃尔玛为例，沃尔玛提供了两种对接方案，分别是API和EDI。供应商在向沃尔玛请求获取订单时，如果选择API调用，就需要定时向沃尔玛发送请求，建立连接，主动获取订单。而如果使用EDI，沃尔玛产生订单后会主动推送至客户系统，无需重复请求。在订单量较大的情况下，API调用还有可能存在并发问题。

这也是为什么沃尔玛要求供应商如果一年的订单量预计会超过15000单时，必须要使用EDI来完成对接。总的来说，API和e Di各有优劣，API的使用范围更广，功能层面上也比EDI更强，可以实现更精细化的功能，但技术门槛更高，需要专业开发人员才能实现，这在无形中也增加了成本。EDI则可以看作是API的某种具体实现，为了通用可能损失了一些细节，但其标准化的程度更高，且技术门槛低，只需要普通it和业务人员即可实现，成本更低。

我将本视频关于API和e Di的内容整理成了表格，大家有需要的话可以截图保存。API和e Di并非非此即彼的相对关系，企业可以将其融合，在标准化的同时，实现更贴近自己内部的业务。API和EDI可不两者间的呢。如果大家对此有什么疑问，可以通过以上方式联系我们，感谢您的关注。更多EDI相关内容可以访问知行软件官网。