Feature Request: Add GET portion to new HTTP api

[mark-epstein]

Is this a feature relevant to companion itself, and not a module?

• I believe this to be a feature for companion, not a module

Is there an existing issue for this?

• I have searched the existing issues

Describe the feature

Don't remove the HTTP GET requests, particularly those that set custom variables. The documentation give no specific deadline, but rather leaves it open for my anxiety to interpret.

I understand the stated rationale of trying "to follow REST principles, and the convention that a POST request will modify a value, and a GET request will retrieve values." I'm asking that unless there is a compelling reason other than to adhere to these principles, that the legacy commands be allowed to remain.

Usecases

Sending a POST request is more difficult. Perhaps only minimally so, but I like that I can email a string to someone non-technical. have them paste that string in a browser address bar, and they're done. I use this to actuate buttons on pages they can't reach from the Stream Deck, or to set variables.

I make extensive use of PowerPoint's ability (via IrisDown's RSC) to launch web requests, so that slides in my presentation will trigger companion events. These are invaluable for keeping PowerPoint and Companion in sync instead of requiring a user to advance a slide and press one or more Companion button(s) simultaneously.
GET requests are the only type Remote Show Control supports.

[mark-epstein]

Incidentally I did reach out to Irisdown who suggested they might make a modification to RSC to support POST requests. This would solve the second use case I posted, but not the first.

[Julusian]

There isn't a deadline because there isn't a well defined plan in what will be in each Companion release, its gets decided based on what gets done. I can say that I won't be removing this stuff in 3.3, and I probably wont in 3.4. Tbh there is no compelling reason to remove it yet, so it could well end up staying for multiple releases.

Changing GET to POST wasn't the main motivator for the api change, that was driven by needing to support the page/row/column syntax, and the opportunity was taken to also conform properly to REST principles.
So the old api won't be reinstated, but a new GET portion could be added to the new api to allow for your use cases. I am tempted to say it should be disabled by default as its use should be discouraged (doing a POST should be preferred when possible)