談到耦合系統(tǒng)，REST（Representational State Transfer）幾乎總是起著關鍵作用。特別是在與啟用 Web 的系統(tǒng)相關的方面，REST 是系統(tǒng)集成的領先標準之一。然而 REST 絕不是全新的；相反，REST 背后的概念是久經(jīng)考驗的。由于設計簡單，通過 REST 連接系統(tǒng)既簡單又有效。而且因為它是無狀態(tài)的，所以很容易擴展。在工業(yè)領域，很多地方都用到了REST。我們在這里為您提供有關 REST 的必要基礎知識。

內(nèi)容

一、REST的核心思想

REST

“Representational State Transfer” (REST) 的概念包含軟件系統(tǒng)（客戶端-服務器）之間數(shù)據(jù)交換的軟件架構。與其他架構相比的特點是實現(xiàn)非常簡單、資源集中和無狀態(tài)。
通過 REST 進行的所有通信都集中在資源上，而不是操作上。資源總是唯一尋址，然后可以執(zhí)行創(chuàng)建、讀取、更改或刪除等基本操作。在此上下文中，無狀態(tài)意味著所有描述性參數(shù)都在客戶端和服務器之間交換。這里的優(yōu)點是沒有會話。沒有會話，客戶端和服務器系統(tǒng)可以自由擴展，因為每個 REST 調(diào)用都是獨立完成和理解的，沒有前面或后面的調(diào)用。

2. REST API/接口

REST API 炸雞

API（Application Programming Interface）是具體系統(tǒng)對REST架構的各自實現(xiàn)。然后它被稱為 RESTful API。可以通過 REST 尋址的資源在接口中定義。
對于相應的資源，存在描述資源并通過 REST 修改的關聯(lián)參數(shù)。
對于系統(tǒng)的RESTful API，提供者通常會提供API文檔，在文檔中可以查看所有資源及其參數(shù)。
一個好的 API 文檔的例子是我們的票證系統(tǒng) Target Process 的 REST 接口，可以在這里查看：  Target Process REST API。
在生產(chǎn)環(huán)境中，支持 REST 的系統(tǒng)可能會提供以下資源，例如：

  • /生產(chǎn)/生產(chǎn)訂單
    • 參數(shù)：ID、訂單號、數(shù)量、產(chǎn)品、截止日期……
  • /production/production-order/{id}/component.
    • 參數(shù)：ID、料號、數(shù)量、批次、……
  • /生產(chǎn)車間
    • 參數(shù)：ID、狀態(tài)、當前訂單、下次維護、營業(yè)時間……

3.REST 和 HTTP

Representational State Transfer 的架構思想沒有規(guī)定實現(xiàn)的技術。然而，在實踐中，REST 總是通過HTTP 協(xié)議實現(xiàn)的。這些資源使用唯一的URI（統(tǒng)一資源標識符）尋址，如 Web 瀏覽器所知。資源的參數(shù)作為查詢附加（也稱為 URL 參數(shù)）。
對資源的操作是在 HTTP 中通過標準操作 GET、POST、PUT 和 DELETE 實現(xiàn)的。以下標準適用：

  • GET 檢索一個或多個資源
  • POST 創(chuàng)建資源的新實例
  • PUT 將數(shù)據(jù)寫入資源并因此更改它
  • DELETE 刪除資源實例

從支持 REST 的 ERP 系統(tǒng)檢索特定生產(chǎn)訂單的 REST 調(diào)用可以通過現(xiàn)有的 http 連接看起來像這樣：

獲取 http://ERPSYSTEM/Produktionsauftrag/4711
接受：application/json

第二行向 ERP 系統(tǒng)指定響應的格式。

JSON 格式的可能響應是：

[
{
?id“: ?4711“,
?Artikel“: “Produkt A”,
?Menge“: ?10500,
?Freigabe“: false,
?Lieferdatum”: ?21.7.2020“
}
]

4.例子

REST Open Weather mit dem OPC Router

可以嘗試 REST 調(diào)用的真實示例，例如，在天氣預報服務 OpenWeatherMap 的頁面上。

如果使用 Web 瀏覽器調(diào)用鏈接（每次點擊），則會向服務發(fā)送GET請求。結果，該服務響應倫敦位置的天氣預報。
在這種情況下，端點是：api.openweathermap.org/data/2.5/forecast
資源是“預測”，其相關參數(shù)“q”代表位置，“模式”代表格式。有關如何調(diào)用此 API 的詳細示例，請參閱我們的使用 OPC Router從 OpenWathermap 檢索天氣數(shù)據(jù)的說明文章。

5.數(shù)據(jù)格式

REST 端點響應的數(shù)據(jù)格式?jīng)]有規(guī)定，因此原則上可以是任意的。實際上，格式取決于端點的功能。在大多數(shù)情況下，數(shù)據(jù)以JSON或XML文檔的形式提供。如果通過 REST 調(diào)用查詢普通網(wǎng)頁，則響應為 HTML。
XML/JSON 響應的結構必須由 REST 接口的操作員記錄，因為這里不可能進行自我描述。

讓您的系統(tǒng)通過 REST 相互通信

立即使用 REST 插件測試 OPC Router，免費且無義務。

免費測試 REST 連接

6.服務/網(wǎng)絡服務

就軟件而言，網(wǎng)絡服務或服務是指允許不同軟件系統(tǒng)之間進行數(shù)據(jù)交換和協(xié)作的服務。Web 服務通過標準 Web 技術在 Web 上實現(xiàn)了這一點。其中，REST 是 Web 服務實現(xiàn)的具體體現(xiàn)。其他的是，例如，SOAP或 RPC（遠程過程調(diào)用）。

7. 帶有 REST 的傳感器

許多帶有內(nèi)置小型計算機的現(xiàn)場設備也通過 REST 提供它們的數(shù)據(jù)。這樣，這些現(xiàn)場級設備可以很容易地集成到其他應用程序中。
這方面的示例是 I/O 模塊（例如來自WuT）或能量測量設備（例如來自 Phoenix Contact）。
對于控制器 (PLC) 和其他遠程數(shù)據(jù)源，Kepware OPC 服務器還提供了通過 REST 服務器提供數(shù)據(jù)的可能性。

8. 帶有 REST 的軟件系統(tǒng)

REST 接口廣泛用于軟件系統(tǒng)（例如 ERP、MES、PLS），尤其是基于云的系統(tǒng)中的 Web。有了裝備精良的 API，軟件系統(tǒng)的幾乎整個功能范圍都可以通過接口來處理，或者，也可以創(chuàng)建用戶特定的 REST 端點。
這方面的示例包括SAP with REST via PI、Microsoft with the REST API for Dynamics 365或Siemens Mindsphere REST API。然而，最終，值得向制造商詢問每個使用的軟件系統(tǒng)的 REST API。

9.終點

REST 端點

端點是構成相應 REST API 的完整 URI。所有端點的總和就是 API，而各個端點恰好指向一個資源。對于生產(chǎn)訂單的示例，查詢一組組件的端點可能如下所示：

/Produktionsauftrag/{id}/Komponente/{id}/Menge

在此端點，訂單和組件的編號作為 ID 傳輸。

10. OPCRouters和REST

OPC Router和 REST

OPC Router在調(diào)用 REST API 時用作客戶端（請參閱 REST 插件）。在 OPC Router中，端點被配置為調(diào)用，然后在連接中被調(diào)用。方法、端點和參數(shù)隨后在傳輸對象中可見。

可以在此處找到詳細示例：使用 OPC Router從 OpenWathermap 檢索天氣數(shù)據(jù)的操作方法文章。

除了調(diào)用 REST 端點外，OPC Router還可以充當服務器并定義 REST 端點。為此，OPC Router提供了所謂的 REST 觸發(fā)器。這樣，可以使用 OPC Router構建自己的 REST API。

11. Postman – 測試API客戶端

郵差

有多種工具可以快速輕松地測試 REST 接口。最著名的人之一是郵遞員。一個非常強大的程序，用于調(diào)用和創(chuàng)建 API。Postman 可以在這里下載：  Postman REST API Client。

12. Swagger——API 描述框架

昂首闊步

Swagger 框架用于創(chuàng)建、使用和記錄 Web 服務。這對 REST 客戶端特別有用，因為通過 Swagger 記錄的 REST API 提供了標準化文檔，因此可以在客戶端瀏覽界面。此瀏覽功能不包含在 REST 的核心思想中，在此進行補充。

13. REST 的歷史

Web 服務從一開始就是分布式軟件系統(tǒng)中的一個重要主題。許多技術很快變得非常強大并提供了許多功能。對于較小的應用程序，這些應用程序通常已經(jīng)過于復雜且計算量太大。
2000年，美國計算機科學家羅伊·菲爾丁以此為契機，設計了一種全新的、簡單的架構。他因此被授予博士學位。從那時起，REST 得到廣泛應用，成為互聯(lián)網(wǎng)上最重要的系統(tǒng)耦合技術之一。

14. REST 的未來——GraphQL

REST的架構模型是固定的，按原樣運行。REST 查詢中缺乏結構導致了采用 REST 架構思想并進一步發(fā)展的新發(fā)展。Facebook 于 2012 年開發(fā)了 GraphQL 架構，并于 2015 年發(fā)布。與 REST 一樣，GraphQL 是一種無狀態(tài)查詢語言。在其他一些改進中，GraphQL 定義了模式。這定義了端點如何響應以及響應中數(shù)據(jù)的結構。因此，GraphQL 改進了 REST 最大弱點之一的架構。

立即注冊時事通訊

隨時了解并訂閱我們的 OPC Router時事通訊。

訂閱時事通訊

15. REST 中的安全性

由于使用 HTTP 調(diào)用 REST 端點，因此也可以使用標準中可用的身份驗證，例如：HttpBasic、Jwt、Ntml、OAuth1、OAuth2。
此外，為了使用防竊聽連接，當然使用 https 代替 http。
除了標準的身份驗證選項外，通常還會交換所謂的 AppKey。此密鑰是為客戶創(chuàng)建的密碼，每次呼叫時都會傳輸該密碼，以便獲得呼叫授權。OPC Router也支持所謂的 Bearer Token。由于使用了廣泛使用的方法，REST 被認為是安全的。