设计REST API架构和实现

Question

目前，我正在设计和编程一个控制一系列设备的软件。该软件计划具有REST接口，通过该接口，您可以远程控制软件（和设备）。

现在，架构的一个非常基本的抽象可能看起来像这样：

您可以注意到，系统由主控制器组成，然后主控制器处理和监视不相互依赖的不同模块。前端模块是图中的示例，而其他模块是模块的一般抽象，但它们可以是任何东西（数据库模块，MessageBus模块等）。 对于实际的REST接口，有数据检索，数据存储以及正在实现的控制命令。

我的“问题”是我无法决定这些“命令”应该如何传播到线上。 一些可能的命令案例：

• 要求打开/关闭，重新启动，控制由其他模块处理的设备的命令
• 请求重新启动/重新加载软件的命令
• 从其他模块检索数据的命令

现在我看到了实际逻辑实现的几种可能方式：

• 所有收到的REST命令都通过消息总线分派。在这种情况下，每个请求都应该接收一个唯一的标识符，然后可以使用该标识符来检索请求的状态
• 所有收到的REST命令都会直接调用其他模块

这两者都有利有弊： 执行所有操作的第二种方法很容易陷入意大利面条代码，并且难以调试和扩展，因为通过不同的模块有很多多线程利用。但它可能是处理命令和检索数据的最快方法。特别是因为该项目需要速度和响应能力。 第一种方法缺乏第二种方法的优点，但它有助于保持代码和体系结构的清洁，并清除其他模块的依赖性。此外，还计划了一个控制台渠道，理论上可以使用相同的方法进行实施。

在对问题进行头脑风暴时，我还想到了另一种方法： 强制REST通道将传入的请求转发到实际的FronEnd模块，然后“等待”直到收到响应。然后，FrontEnd模块必须直接调用其他模块以获取所请求的任何信息或操作。 然而，该方法与方法nr 2并不“不同”。

有人可以提供任何建议吗？也许有关实施或设计决策的想法？

如果你想知道，该软件是用Python编写的，但我不认为这与这个问题有关。

Answer 1

所以基本上我们已经决定放弃RESTful方式，而只是使用套接字（特别是websockets）来实现一种方法。

通过websockets发送的命令被格式化为JSON并且在某种程度上类似于REST（基本上是请求包含“URI”，“动作”[获取，放置，发布等]和“正文”）。

命令到达系统的前端控制部分，然后被推送到消息总线，系统的另一部分已经订阅了这些命令。处理完数据或执行命令后，数据将通过消息总线返回，并通过websocket发送给客户端。