跳到主要内容

使用REST消息传递

代表性状态转移（REST）是一种设计网络应用程序的轻量级方式。它允许客户端和网络事件代理使用标准 HTTP 方法（如 POST）进行通信。实现 REST 的系统被称为 RESTful 系统。RESTful 系统以符合 HTTP 协议定义（RFC 2616）的方式使用 HTTP 方法。

REST 不是一种定义好的标准，而是一套指导原则。

REST概念​

如果您之前没有一起使用过 REST 和 Solace PubSub+，您可能想看看概述：应用程序如何与 PubSub+ 消息传递组件交互页面的 REST 部分。它将带您参观 PubSub+ 事件代理的消息传递组件，并在高层次上解释它们如何使用 REST 将数据从生产者传输到代理，再从代理传输到消费者。

REST生产者和消费者​

Solace REST 协议中有两个主要角色：

  • REST 生产者 — 向事件代理发送消息
  • REST 消费者 — 从事件代理接收消息

REST生产者​

REST 生产者是向事件代理中的主题或队列发送 REST 消息的应用程序。为了向事件代理发送消息，REST 生产者必须与事件代理建立客户端连接。事件代理在 REST 生产者使用基本认证方案或客户端证书认证方案连接时对其进行认证。Solace REST 实现不支持 Kerberos 认证。使用基本认证方案的客户端可以通过不指定用户名或密码以匿名发布者的身份连接。

经过认证的连接 REST 生产者的权限由标准 Solace 配置参数决定，例如客户端配置文件和 ACL 配置文件。

已与事件代理建立客户端连接的 REST 生产者被视为普通客户端，并且可以使用 Solace CLI 命令（如 show client User EXEC 命令）查看。

有关事件代理如何认证客户端实体以及用于为其提供服务的授权过程的详细信息，请参阅客户端授权和客户端认证。

REST消费者​

要从 Solace PubSub+ 事件代理消费消息，需要 REST 消费者 REST 交付点（RDP）对象。RDP 对象在事件代理上的消息 VPN 中进行配置。连接到事件代理的物理 REST 应用程序可以绑定到 RDP 以消费来自它的 REST 消息。RDP 包含以下组件：

  • REST 消费者
  • 客户端配置文件
  • 队列绑定

REST 消费者​

REST 消费者是在消息 VPN 中代表物理 REST 消息消费者（即客户端应用程序）的虚拟对象。

每个由 RDP 服务的物理消费者通过其 IP 地址或主机名以及 TCP 端口号来识别。一个 RDP 可以为多个 REST 消费者提供服务。当一个 RDP 为多个 REST 消费者提供服务时，事件代理通过选择将每条消息传递给哪个 REST 消费者来执行负载均衡功能。

事件代理可以在与 REST 消费者建立连接时使用认证（基本认证、客户端证书认证或无认证）。

客户端配置文件​

RDP 必须分配与 RDP 在同一消息 VPN 中的现有客户端配置文件。RDP 使用绑定的客户端配置文件的 TCP 参数和出站队列属性。

队列绑定​

RDP 还包含队列绑定，这是对事件代理上持久消息端点的引用。RDP 只能绑定到与 RDP 在同一消息 VPN 中的持久队列。

当 RDP 绑定到队列时，传递到该队列的消息将被 RDP 吸引，然后安排传递给为 RDP 配置的 REST 消费者之一。

如果删除了队列，引用已删除队列的任何队列绑定将保持完整，但这些队列绑定将无法运行。要投入使用，RDP 必须至少有一个运行中的队列绑定。队列绑定全部无法运行的 RDP 无法投入使用。

REST消息结构​

发送到和来自事件代理的 REST 消息使用 HTTP POST 方法。POST 结构取决于消息是请求还是响应，以及消息是发送到还是来自事件代理。

Solace REST 接口使用标准 HTTP 标头（如 Content-Length）和 Solace 特定的 HTTP 标头（如 Solace-Client-Name）。仅在 Solace REST 接口中使用且由事件代理内部使用的 HTTP 标头以前缀 Solace- 开头。为了避免混淆，应用程序不应使用以 Solace- 开头的 HTTP 标头。有关 Solace PubSub+ 特定的 HTTP 标头的完整列表，请参阅 Solace REST 对 HTTP 标头的使用。

REST 消息的正文是消息的 HTTP 标头之后传输的数据。当 REST 消息到达事件代理时，这些数据被封装在 Solace 消息负载中，该负载可以有多种格式，包括文本或二进制。消息可以选择省略消息正文。

REST消息结构示例​

以下是基于来源和消息类型的 REST 消息的一些可能配置。

不要求发布者和订阅者之间的通信仅限于 REST 或仅限于非 REST。例如，REST 客户端可以接收 REST 消息并以 Solace 消息格式（SMF）消息进行响应。事件代理将根据消息格式将消息传递到其目的地。

发布到事件代理的 REST 消息​

从发布者发送到事件代理的 REST 消息由 POST 请求、HTTP 标头和 HTTP 消息正文组成。事件代理使用 POST 请求确定消息的路由位置，HTTP 标头指定可能决定消息处理方式的消息属性。POST 请求的正文作为消息负载包含在内。

来自事件代理的 REST 消息确认​

当事件代理成功接收 REST 消息时，它会以 POST 响应的形式发送确认（“ack”）。对于保证消息，事件代理会在成功将消息写入磁盘后才发送 POST 响应。

ACK 由响应代码（通常是 200 OK）和 HTTP 标头组成。由于响应代码足以确认原始消息的接收，因此返回的消息具有空的消息正文。

来自消费者的 REST 响应​

如果使用请求/回复交换模式，当消费者回复 REST 请求消息时，它会报告自己的响应代码（200 OK）、新的 HTTP 标头和消息正文。如果消费者回复的消息是消息，则消息正文将包含要返回给原始发布者的消息负载信息。

消息交换模式​

本节描述了使用 REST 消息传递与 Solace PubSub+ 时可能发生的消息交换模式。

REST生产者单向POST到事件代理​

下图显示了一个 REST 生产者向事件代理发送消息的交换模式。

REST 生产者单向 POST 到事件代理

img

在此场景中，REST 生产者通过将请求指向由事件代理的 IP 地址或主机名、端点类型（队列或主题）以及队列或主题名称组成的 URL，将消息作为 POST 请求发送到事件代理。事件代理根据消息的传递模式是直接传递还是持久化而有不同的行为。

如果消息的 Solace-Delivery-Mode 是 direct，在接收到消息后，事件代理会向 REST 生产者发送一个 200 OK 的 POST 响应，然后传递消息。POST 响应并不表明消息已传递给其消费者，而仅表明事件代理已接收消息。

如果消息的 Solace-Delivery-Mode 是 persistent 或 non-persistent，当事件代理接收到消息时，它会将消息存储在消息池中，然后向 REST 生产者发送一个 200 OK 的 POST 响应。同样，对 REST 生产者的 POST 响应仅表明事件代理已接收消息，并不表明消息已被传递。然后事件代理尝试传递消息。

由于多种原因，REST 生产者向事件代理发送的消息可能会失败。如果在将 REST 生产者与事件代理认证时发生错误，或者消息格式有误，事件代理将返回一个包含错误详细信息的 POST 响应。您收到的错误响应取决于消息的 Solace-Delivery-Mode 是 direct 还是 persistent（或 non-persistent）。有关 POST 响应的详细信息，请参阅 Solace REST 状态代码。

事件代理单向POST到REST消费者​

下图显示了一个涉及事件代理向 REST 消费者传递消息的场景。

事件代理单向 POST 到 REST 消费者

img

在此场景中，事件代理已接收消息，并确定该消息将由 REST 消费者接收。如果消息类型是持久化的，事件代理将存储消息并保留它，直到确认传递。

通过 POST 请求将消息传递到 REST 消费者，该请求包含在消息中的固定 URL（在 REST 消费者中配置）。在接收到消息后，REST 消费者会向事件代理发送一个 200 OK 的 POST 响应以确认消息。

如果消息类型是持久化的，事件代理在收到 200 OK 响应时会从消息池中删除消息。由于这是一个单向消息传递，REST 消费者响应正文中的任何信息都将被丢弃。

如果事件代理收到的响应状态码不是 200 OK，它将继续尝试传递消息，直到传递成功或满足其他条件（例如，最大重试参数超出）。

REST生产者请求/回复到事件代理​

下图显示了 REST 生产者如何向任何消息消费者发送消息，并指定希望收到回复消息。

REST 生产者请求/回复到事件代理

img

REST 生产者发送一个包含 Solace-Reply-Wait-Time-In-ms 标头的初始 REST 消息。此标头表明期望收到回复消息。

如果消息的 Solace-Delivery-Mode 是 direct，事件代理在接收到消息时，会将 REST 消息编码为 SMF 消息，并以指定的传递模式将其发送给消费者。如果消息的 Solace-Delivery-Mode 是 persistent 或 non-persistent，事件代理会在发送消息之前将其写入磁盘。

消费者用它自己的消息回复，其中包括对原始消息的回复。在收到此回复时，事件代理会从回复中构造一个 REST POST 响应，并将状态代码 200 OK 和回复消息的内容作为 HTTP 消息负载，将其传递给原始生产者。

在此场景中，由于多种原因，包括等待时间超时或回复消息格式不受支持，可能会发生传递失败。

事件代理请求/回复到REST消费者​

下图显示了请求/回复消息也可以从非 REST 源发起。

事件代理请求/回复到 REST 消费者

img

此场景类似于事件代理到 REST 消费者的单向 POST。然而，在这种情况下，REST 消费者从事件代理收到的 POST 包含 Solace-Reply-Wait-Time-In-ms 标头。这表明事件代理期望对消息进行回复。

REST 消费者将其回复编码在返回给事件代理的 POST 响应的 HTTP 消息正文中。如果正确接收了原始消息，则响应消息的状态代码为 200 OK。

即使例如在处理消息时出现错误，200 OK 响应也表明已接收消息。如果需要，REST 消费者可以将有关任何错误的详细信息编码在 200 OK 响应的正文中。

REST生产者请求与异步回复到目的地​

下图显示了应用程序如何使用 REST 发送消息并接收异步回复。

REST 生产者请求与异步回复到目的地

img

在此场景中，应用程序既充当 REST 生产者又充当 REST 消费者（即，它使用 HTTP POST 发送和接收消息）。作为 REST 生产者，它将消息作为 POST 发送到事件代理，包括 Solace-Reply-To-Destination 标头。事件代理从 POST 中读取回复到的信息和目的地。

事件代理如果消息是持久化的，则将消息存储在消息池中。然后，它在将消息发送给最终消费者之前，向 REST 生产者返回一个 200 OK 状态响应。

当最终消费者收到消息时，它从原始 POST 中提取消息的回复到信息。消费者将其回复发送回事件代理，回复再次被写入磁盘。

事件代理通过 POST 将回复消息传递给原始应用程序，其连接参数作为事件代理上的 RDP 中的 REST 消费者存储。当应用程序收到最终回复消息时，它向事件代理发送一个 200 OK，以表明该序列已完成。