Designing REST API architecture and implementation

Currently I am designing and programming a piece of software that controls a series of devices. The software is planned to have a REST interface through which you would be able to control the software (and the devices) remotely.

Now, a very basic abstraction of the architecture could look something like this:

As you can note, the system is composed of a master controller, which then handles and monitors different modules that are not dependent on each other. Front End module is an example in the diagram, while others are general abstractions of modules, but they could be anything (Database module, MessageBus module, etc). For the actual REST interface there are both data retrieval, data storage, as well as control commands that are being implemented.

My "problem" is that I can't decide on how these "commands" should be propagated down the line. Some cases of possible commands:

• Command requesting to turn on/off, restart, control a device handled by another module
• Command requesting to restart/reload the software
• Command to retrieve data from another module

Now I see a few possible ways of the actual logic implementation:

• All received REST commands are dispatched through a message bus. In this case each request should receive a unique identifier which could be then used to retrieve the status of the request
• All received REST commands make direct calls to other modules

Both of these have pros and cons: The second method of doing everything could very easily fall into spaghetti code and would be hard to debug and expand upon, since there's a lot of multithreading utilization through different modules. But it is possibly the fastest way of handling a command and retrieving data. Especially since the project requires speed and responsiveness. The first method lacks the advantages of the second method, however it would help to keep the code and architecture clean and clear of dependencies from other modules. Furthermore, a Console channel is also planned which could in theory use the same methodology for implementation.

There's another method that I thought of while brainstorming about the problem: To force the REST channel to forward the incoming requests to the actual FronEnd module and then "wait" until it receives a response. The FrontEnd module would then have to directly call other modules for any information or actions requested. This method, however, is not that "different" from the method nr 2.

Could anyone offer any advice? Perhaps ideas on the implementation or design decisions?

In case you are wondering, the software is being written in Python, but I don't think this is relevant to the question.