[Share] EDI 及其他常见系统对接技术
近期，有客户提及：你们有没有对接技术相关的介绍，不同系统之间的对接技术，现在企业内部系统比较多，有自主开发的，有外部采购的，所以我们想了解一下对接技术相关的信息。
小知马不停蹄的做了下功课， 整理了相关信息，详情如下！
系统对接方式
一般情况下，常见的不同系统之间的对接方式有两种，一种是消息集成，另外一种是 API 调用，两者各有利弊。
消息
消息，是一个数据通道，可以对数据进行加密或对数据通道进行加密，安全性高，但是在进行大量数据传输时，可能会存在延迟。
API 调用
API，是调用 http 接口，知行 EDI 系统可以封装好接口，开放 API 供其它系统调用，不过这种方式就是安全性没那么高，但是具有实时性。
总的来说，消息传输具有高安全，高延迟的特点，而 API 则相反，具有低安全，低延迟的特点。如果是组织内部系统的对接，对数据的实时性要求较高，建议采用 API 调用方式，如果是组织内部和外部进行系统对接，对数据的安全性要求较高，建议采用消息的方式。
常见的系统对接技术
小知带大家一起了解下常用系统对接技术，本文主要提及 EDI，Web 和 WebService，REST和JDBC。这五种对接方式，较于 EDI，大家应该更熟悉后面四种技术。其中，EDI 是 属于消息集成方式； Web 是 EDI 的一种临时替代方案； WebService，REST 和 JDBC 均属于 API 调用集成方式。
EDI
用于和外部交易伙伴做核心业务数据传输（解决的是企业间的问题）属于消息集成方式。
EDI 自 20 世纪 60 年代以来就被广泛使用，但如今它正在被应用于更多新的用途，使供应链自动化、数字转换成为可能，甚至成为工作流和业务流程自动化的一个关键部分。点击下方链接，对 EDI 进行全面的解读，帮您短时间内快速掌握 EDI 基础知识。
扩展阅读： EDI 是什么？
如您想了解更多关于 EDI 知识，可联系 EDI 通信专家小知，很乐意为您答疑解惑。
Web
这里的 Web 是指一个 Web 页面，类似于 Portal 网站，通过提供指定用户及密码的方式，授权用户登录 Web 网页登录，去查看相关业务数据，并填写表单数据，提交给后台。 Web 方式是 EDI 的一种替代方案，主要提供给不具备 EDI 能力的合作伙伴使用，以此实现业务数据传输。
基于小知过往的实施经验，了解到提供 Web 方式的，汽车行业主机厂居多，比如 Tesla/特斯拉，上汽大众等。
WebService
WebService的特征：
- 基于 SOAP 协议的，数据格式为 XML
- 只支持 HTTP 协议
- 不是开源的，但可以被任意一个了解 XML 的人使用
- 只能部署在 IIS 上，WebService 是两个系统间的远程调用，使两个系统进行数据交互，如应用：天气预报服务、银行ATM取款、使用邮箱账号登录各网站等。
WebService核心组件：
- XML和HTTP
- SOAP： 简单对象访问协议
- WSDL： WebService 描述语言
- UDDI：统一描述、发现和集成协议
WebService 之间的调用是跨语言的调用，发送 Http 请求，使用的数据格式是 XML 格式。
假设一个 Web Service A 提供允许其他应用程序通过 URL 获取用户信息的功能：[GET] http://www.abc.com/{id}。id是用户的唯一标识符，请求此 URL 将获得用户信息。现在假设浏览器、手机、桌面应用程序的用户都要获取服务 A 提供的用户信息，这三者只需要请求服务 A 提供的 URL 地址，并输入用户 id 信息即可。至于这三个不同客户端的实现方式（编程语言）是什么与服务 A 没有任何关系，只要能够解析出服务 A 返回的 XML 文档即可。这样，应用程序之间交换数据就可以不用依赖于具体的语言和环境。这就好比不同国家不同语言的人，只要能够知晓对方语言的语法结构，两个人就可以进行交流。
目前，WebService 主要有两大流派：
- 基于 SOAP 的 WebService : SOAP（简单对象访问协议）是一种基于 XML 的协议，用以访问 Web Service。其接口以机器可处理的格式进行描述，称为 WSDL(Web服务定义语言)文档。通过使用标准的的 XML 文档来描述 Web Service，在 XML 文件中，会详细记录接口的信息，如消息的格式、传输协议以及交互的位置等信息。
- 基于 REST 的 WebService ：REST（Representational State Transfer）是一种软件架构，它使用 JSON 来描述数据格式，最重要的是 HTTP 传输协议对 REST 来说是非必须的。
WebService 属于 API 调用集成方式。
REST
REST 是一种设计 API 的模式。最常用的数据格式是 JSON。由于 JSON 能直接被 JavaScript 读取，所以，以 JSON 格式编写的 REST 风格的 API 具有简单、易读、易用的特点。
REST 是Representational State Transfer（表现层状态转移）的缩写，它是由罗伊·菲尔丁（Roy Fielding）提出的，是用来描述创建 HTTP API 的标准方法的，他发现这四种常用的行为（查看（view），创建（create），编辑（edit）和删除（delete））都可以直接映射到 HTTP 中已实现的 GET,POST,PUT 和 DELETE 方法。
REST 是面向资源的，这个概念非常重要，而资源是通过 URI 进行暴露。URI 的设计只要负责把资源通过合理方式暴露出来就可以了。对资源的操作与它无关，操作是通过 HTTP 动词来体现，所以 REST 通过 URI 暴露资源时，会强调不要在 URI 中出现动词。比如：左边是错误的设计，而右边是正确的。
GET /rest/api/getDogs --> GET /rest/api/dogs 获取所有小狗狗
GET /rest/api/addDogs --> POST /rest/api/dogs 添加一个小狗狗
GET /rest/api/editDogs/:dog_id --> PUT /rest/api/dogs/:dog_id 修改一个小狗狗
GET /rest/api/deleteDogs/:dog_id --> DELETE /rest/api/dogs/:dog_id 删除一个小狗狗
左边的这种设计，很明显不符合 REST 风格，上面已经说了，URI 只负责准确无误的暴露资源，而 getDogs/addDogs…已经包含了对资源的操作，这是不对的。相反右边却满足了，它的操作是使用标准的 HTTP 动词来体现。
REST 很好地利用了 HTTP 本身就有的一些特征，如 HTTP 动词、HTTP 状态码、HTTP 报头等等，REST API 是基于 HTTP 的，所以你的 API 应该去使用 HTTP 的一些标准。这样所有的 HTTP 客户端（如浏览器）才能够直接理解你的 API（当然还有其他好处，如利于缓存等等）。REST 实际上也非常强调应该利用好 HTTP 本来就有的特征，而不是只把 HTTP 当成一个传输层这么简单了。
HTTP 动词
- GET 获取一个资源
- POST 添加一个资源
- PUT 修改一个资源
- DELETE 删除一个资源
实际上，这四个动词实际上就对应着增删改查四个操作，这就利用了 HTTP 动词来表示对资源的操作。
通俗的讲 REST 就是：
- 看 Url 就知道要什么
- 看 http method 就知道干什么
- 看 http status code 就知道结果如何
更简洁的来说，就是用 URL 定位资源，用 HTTP 描述操作。
REST 是属于 API 调用集成方式。
JDBC
JDBC（Java Data Base Connectivity,java数据库连接）是一种用于执行 SQL 语句的 Java API，可以为多种关系数据库提供统一访问，它由一组用 Java 语言编写的类和接口组成。JDBC 提供了一种基准，据此可以构建更高级的工具和接口，使数据库开发人员能够编写数据库应用程序。
JDBC 是对数据库操作的接口抽象，而不同数据库厂商的数据库驱动程序则对应 JDBC 接口实现，通过抽象出 JDBC 接口，应用程序和实际的数据库驱动，即JDBC实现解耦。
常用的 JDBC 接口包括：Driver 接口、Connection 接口、Statement 接口、ResultSet 接口。
JDBC API 允许用户访问任何形式的表格数据，尤其是存储在关系数据库中的数据。
执行流程：
- 连接数据源，如：数据库。
- 为数据库传递查询和更新指令。
- 处理数据库响应并返回的结果。
JDBC是属于 API 调用集成方式。
以上的资料集锦，希望对阅读本文的有缘人提供一定的帮助。如有描述不妥或有争议的地方，欢迎一起探讨。