python - 设计 REST API 架构和实现

Question

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

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

正如您所注意到的，该系统由一个主 Controller 组成，该 Controller 负责处理和监控彼此不依赖的不同模块。前端模块是图中的一个示例，而其他模块是模块的一般抽象，但它们可以是任何东西(数据库模块、消息总线模块等)。对于实际的 REST 接口(interface)，有数据检索、数据存储以及正在实现的控制命令。

我的“问题”是我无法决定这些“命令”应该如何向下传播。可能命令的一些情况:

• 请求打开/关闭、重启、控制由另一个模块处理的设备的命令
• 请求重启/重新加载软件的命令
• 从另一个模块检索数据的命令

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

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

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

我在头脑 Storm 时想到了另一种方法:强制 REST channel 将传入请求转发到实际的 FronEnd 模块，然后“等待”直到它收到响应。然后，前端模块将不得不直接调用其他模块以获取所请求的任何信息或操作。然而，这种方法与方法 2 并没有那么“不同”。

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

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

Answer 1

所以基本上我们已经决定放弃 RESTful 方式并简单地选择使用套接字(或特别是 websockets)的方法。

通过 websockets 发送的命令被格式化为 JSON，并且在某种程度上类似于 REST(基本上一个请求包含一个“URI”、一个“Action”[get、put、post 等] 和一个“body”)。

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