.png){kind=logo}
谈到耦合系统，REST（Representational State Transfer）几乎总是起着关键作用。特别是在与启用 Web 的系统相关的方面，REST 是系统集成的领先标准之一。然而 REST 绝不是全新的；相反，REST 背后的概念是久经考验的。由于设计简单，通过 REST 连接系统既简单又有效。而且因为它是无状态的，所以很容易扩展。在工业领域，很多地方都用到了REST。我们在这里为您提供有关 REST 的必要基础知识。
内容
一、REST的核心思想
“Representational State Transfer” (REST) 的概念包含软件系统（客户端-服务器）之间数据交换的软件架构。与其他架构相比的特点是实现非常简单、资源集中和无状态。
通过 REST 进行的所有通信都集中在资源上，而不是操作上。资源总是唯一寻址，然后可以执行创建、读取、更改或删除等基本操作。在此上下文中，无状态意味着所有描述性参数都在客户端和服务器之间交换。这里的优点是没有会话。没有会话，客户端和服务器系统可以自由扩展，因为每个 REST 调用都是独立完成和理解的，没有前面或后面的调用。
2. REST API/接口
API（Application Programming Interface）是具体系统对REST架构的各自实现。然后它被称为 RESTful API。可以通过 REST 寻址的资源在接口中定义。
对于相应的资源，存在描述资源并通过 REST 修改的关联参数。
对于系统的RESTful API，提供者通常会提供API文档，在文档中可以查看所有资源及其参数。
一个好的 API 文档的例子是我们的票证系统 Target Process 的 REST 接口，可以在这里查看： Target Process REST API。
在生产环境中，支持 REST 的系统可能会提供以下资源，例如：
- /生产/生产订单
- 参数：ID、订单号、数量、产品、截止日期……
- /production/production-order/{id}/component.
- 参数：ID、料号、数量、批次、……
- /生产车间
- 参数：ID、状态、当前订单、下次维护、营业时间……
3.REST 和 HTTP
Representational State Transfer 的架构思想没有规定实现的技术。然而，在实践中，REST 总是通过HTTP 协议实现的。这些资源使用唯一的URI（统一资源标识符）寻址，如 Web 浏览器所知。资源的参数作为查询附加（也称为 URL 参数）。
对资源的操作是在 HTTP 中通过标准操作 GET、POST、PUT 和 DELETE 实现的。以下标准适用：
- GET 检索一个或多个资源
- POST 创建资源的新实例
- PUT 将数据写入资源并因此更改它
- DELETE 删除资源实例
从支持 REST 的 ERP 系统检索特定生产订单的 REST 调用可以通过现有的 http 连接看起来像这样：
获取 http://ERPSYSTEM/Produktionsauftrag/4711
接受：application/json
第二行向 ERP 系统指定响应的格式。
JSON 格式的可能响应是：
[
{
„id“: „4711“,
„Artikel“: “Produkt A”,
„Menge“: „10500,
„Freigabe“: false,
„Lieferdatum”: „21.7.2020“
}
]
4.例子
可以尝试 REST 调用的真实示例，例如，在天气预报服务 OpenWeatherMap 的页面上。
如果使用 Web 浏览器调用链接（每次点击），则会向服务发送GET请求。结果，该服务响应伦敦位置的天气预报。
在这种情况下，端点是：api.openweathermap.org/data/2.5/forecast
资源是“预测”，其相关参数“q”代表位置，“模式”代表格式。有关如何调用此 API 的详细示例，请参阅我们的使用 OPC Router从 OpenWathermap 检索天气数据的说明文章。
5.数据格式
REST 端点响应的数据格式没有规定，因此原则上可以是任意的。实际上，格式取决于端点的功能。在大多数情况下，数据以JSON或XML文档的形式提供。如果通过 REST 调用查询普通网页，则响应为 HTML。
XML/JSON 响应的结构必须由 REST 接口的操作员记录，因为这里不可能进行自我描述。
6.服务/网络服务
就软件而言，网络服务或服务是指允许不同软件系统之间进行数据交换和协作的服务。Web 服务通过标准 Web 技术在 Web 上实现了这一点。其中，REST 是 Web 服务实现的具体体现。其他的是，例如，SOAP或 RPC（远程过程调用）。
7. 带有 REST 的传感器
许多带有内置小型计算机的现场设备也通过 REST 提供它们的数据。这样，这些现场级设备可以很容易地集成到其他应用程序中。
这方面的示例是 I/O 模块（例如来自WuT）或能量测量设备（例如来自 Phoenix Contact）。
对于控制器 (PLC) 和其他远程数据源，Kepware OPC 服务器还提供了通过 REST 服务器提供数据的可能性。
8. 带有 REST 的软件系统
REST 接口广泛用于软件系统（例如 ERP、MES、PLS），尤其是基于云的系统中的 Web。有了装备精良的 API，软件系统的几乎整个功能范围都可以通过接口来处理，或者，也可以创建用户特定的 REST 端点。
这方面的示例包括SAP with REST via PI、Microsoft with the REST API for Dynamics 365或Siemens Mindsphere REST API。然而，最终，值得向制造商询问每个使用的软件系统的 REST API。
9.终点
端点是构成相应 REST API 的完整 URI。所有端点的总和就是 API，而各个端点恰好指向一个资源。对于生产订单的示例，查询一组组件的端点可能如下所示：
/Produktionsauftrag/{id}/Komponente/{id}/Menge
在此端点，订单和组件的编号作为 ID 传输。
10. OPCRouters和REST
OPC Router在调用 REST API 时用作客户端（请参阅 REST 插件）。在 OPC Router中，端点被配置为调用，然后在连接中被调用。方法、端点和参数随后在传输对象中可见。
可以在此处找到详细示例：使用 OPC Router从 OpenWathermap 检索天气数据的操作方法文章。
除了调用 REST 端点外，OPC Router还可以充当服务器并定义 REST 端点。为此，OPC Router提供了所谓的 REST 触发器。这样，可以使用 OPC Router构建自己的 REST API。
11. Postman – 测试API客户端
有多种工具可以快速轻松地测试 REST 接口。最著名的人之一是邮递员。一个非常强大的程序，用于调用和创建 API。Postman 可以在这里下载： Postman REST API Client。
12. Swagger——API 描述框架
Swagger 框架用于创建、使用和记录 Web 服务。这对 REST 客户端特别有用，因为通过 Swagger 记录的 REST API 提供了标准化文档，因此可以在客户端浏览界面。此浏览功能不包含在 REST 的核心思想中，在此进行补充。
13. REST 的历史
Web 服务从一开始就是分布式软件系统中的一个重要主题。许多技术很快变得非常强大并提供了许多功能。对于较小的应用程序，这些应用程序通常已经过于复杂且计算量太大。
2000年，美国计算机科学家罗伊·菲尔丁以此为契机，设计了一种全新的、简单的架构。他因此被授予博士学位。从那时起，REST 得到广泛应用，成为互联网上最重要的系统耦合技术之一。
14. REST 的未来——GraphQL
REST的架构模型是固定的，按原样运行。REST 查询中缺乏结构导致了采用 REST 架构思想并进一步发展的新发展。Facebook 于 2012 年开发了 GraphQL 架构，并于 2015 年发布。与 REST 一样，GraphQL 是一种无状态查询语言。在其他一些改进中，GraphQL 定义了模式。这定义了端点如何响应以及响应中数据的结构。因此，GraphQL 改进了 REST 最大弱点之一的架构。
15. REST 中的安全性
由于使用 HTTP 调用 REST 端点，因此也可以使用标准中可用的身份验证，例如：HttpBasic、Jwt、Ntml、OAuth1、OAuth2。
此外，为了使用防窃听连接，当然使用 https 代替 http。
除了标准的身份验证选项外，通常还会交换所谓的 AppKey。此密钥是为客户创建的密码，每次呼叫时都会传输该密码，以便获得呼叫授权。OPC Router也支持所谓的 Bearer Token。由于使用了广泛使用的方法，REST 被认为是安全的。
