设计 REST API 架构和实现

Designing REST API architecture and implementation

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

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

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

我的 "problem" 是我无法决定这些 "commands" 应该如何传播下去。 可能命令的一些情况:

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

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

我在头脑风暴时想到了另一种方法: 强制 REST 通道将传入请求转发到实际的 FronEnd 模块,然后 "wait" 直到收到响应。然后,前端模块将不得不直接调用其他模块以获取所请求的任何信息或操作。 但是,此方法不是方法 nr 2 中的 "different"。

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

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

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

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

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