Headless: ADD an API to monitor and control the headless server

[shadowpanther]

Is your feature request related to a problem? Please describe.

I'm always frustrated when I have to use the stdin/stdout text UI of the headless. It has many problems, for example if the session was closed before you enter your next command, the command would fail.

Additionally, when running the headless in a docker container, you have to attach to the container to even get to the UI.

Describe the solution you'd like

An HTTP REST or WebSockets API implementing most/all of the text UI commands. Optional authentication - configure login/password or secret token in the config file.

Additionally, an option to force the stdout into a "log" mode and disable stdin completely when API is enabled (make the console a non-interactive log, which would be appropriate for container-based usage).

Describe alternatives you've considered

Implementing an external wrapper that tries to work around the pitfalls of the interactive text UI. Like, sending a newline just before a command and hoping that there would be nothing extra happening in the time between it and the command itself.

Additional Context

This would allow to make third-party UIs for managing the headless - web-based, text or graphical. Or implement a bot to proxy the commands to your headless from Resonite itself.

Requesters

Shadow Panther

[Frooxius]

We'd like to add an API to the headless that would allow building automation and other management tools, but I'm not 100 % sure if HTTP REST API is the best choice here.

Notably since it's one directional, it will require frequent polling to get notified of any changes. Something like a WebSocket could work a lot better, since it would let headless push the changes as they happen.

[shadowpanther]

I think that at least part of the commands would still be worth implementing as REST, like just polling the status. It would allow to make stateless automations around it. Scraping various metrics for monitoring would be an example.

[Frooxius]

Implementing two sets of API's would increase the burden on our end though, so we're a lot less likely to prioritize it as a result.

The thought is that if we provide say WebSocket API, this will allow other API's in the middle being built around it. E.g. HTTP REST API could be built as a layer on top of that by the community.

[shadowpanther]

Yeah, I guess this also could be a solution.

[JackTheFoxOtter]

WebSocket API sounds very nice indeed. One thing I'm slightly concerned about is users in-game connecting to the API through the headless if localhost host access is granted. Or would the headless client not be able to connect to its own API / would there be some form of authentication?

[Frooxius]

You'd have to grant the access to the specific port for that to work, so unless you allow that, they won't be able to connect like that.

We could add authentication too for it as well.