当前位置:首页 > IT技术 > Windows编程 > 正文

EDI还是API,企业应该如何选择?
2021-12-13 17:49:14

近年来,由于EDI在国内发展势头愈发强劲,大多数企业IT事业部都接触到了EDI,在了解的过程中,经常会有开发人员提出疑问,相对于传统API的方式而言,EDI究竟有什么优势,能够在全球范围内的推广呢?

总的来说,API和EDI各有优劣,API的使用范围更广,功能层面上也比EDI更强,可以实现更精细化的功能,但技术门槛更高,需要专业开发人员才能实现,这在无形中也增加了成本。EDI则可以看做是API的某种具体实现,为了通用可能损失了一些细节,但其标准化的程度更高,且技术门槛低,只需要普通IT和业务人员即可实现,成本更低。

为了大家能够清晰直观的进行对比,小知特意做了表格:

API

EDI

数据结构

1. 由企业自定义,需要较高的技术和业务能力;

2. 结构灵活,容易发生改变;

3. 一般不易保证向前兼容性。

1. 国际组织定义的商业文档,标准结构,全球通用;

2. 涵盖绝大多数业务场景,结构固定;

3. 版本一致性,兼容性程度高。

数据格式

1. 选择多样化,CSV/XML/JSON等

1. X12/EDIFACT/VDA标准报文,标准化程度高,易于维护。

数据传输

1. 传输协议多种多样。比如:REST,SOAP,WebAPI等;

2. 安全策略,收发流程等需要额外代码实现,开发成本较高;

3. 没有标准的接收回执,防抵赖机制;

4. 没有统一的互操作性测试。

1. 统一的传输协议。比如:AS2,OFTP

2. 简单配置即可实现连接,无开发成本;

3. 协议内置接收回执和防抵赖机制;

4. 多种互操作性测试,保证开箱即用。

我们从以下几个点一起来看看:

数据结构

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,何不两者兼得?

更多EDI相关知识,请参考文章:​    EDI白皮书​


注:文案部分图片及内容来源于网络,版权归原创作者所有,如有侵犯到您的权益,请您联系我进行删除,给您带来困扰,深感抱歉。

了解更多EDI相关信息,欢迎交流。

EDI 顾问Iris

如需转载或者了解更多EDI 相关信息,欢迎联系:137-2065-8862(微信同号)

本文摘自 :https://blog.51cto.com/u

开通会员,享受整站包年服务立即开通 >