近期，有客戶提及：你們有沒有對接技術相關的介紹，不同系統之間的對接技術，現在企業內部系統比較多，有自主開發的，有外部采購的，所以我們想了解一下對接技術相關的信息。

小知馬不停蹄的做了下功課， 整理了相關信息，詳情如下！

#### 系統對接方式

一般情況下，常見的不同系統之間的對接方式有兩種，一種是消息集成，另外一種是 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 基礎知識。

擴展閱讀： <a style="color=blue;" href="[導讀] EDI 是什么？ | EDI通信專家">EDI 是什么？</a>

如您想了解更多關于 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 調用集成方式。

以上的資料集錦，希望對閱讀本文的有緣人提供一定的幫助。如有描述不妥或有爭議的地方，歡迎一起探討。

總結

以上是生活随笔為你收集整理的webservice 实现与his系统对接_[Share] EDI 及其他常见系统对接技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。