Possible to replace POST requirements with GET in source? about harmony-api HOT 5 CLOSED

All of the POST methods effect change in state and are POST for a reason. They should not be GET as that method is just for reading state.

Is there a reason you need them to be GET methods instead?

from harmony-api.

Yes, I have a particular proprietary product (wifi remote control, MX-5000 from URC) that can hit an IP/PORT with a relatively simple string, but that I can't alter to do anything more. So for instance, the easiest way to make one of these devices trigger this API to provide IP/PORT and the rest of a (simple) URL as payload.

Most devices that are IP controlled and supported by this remote use relatively simple listening ports, and accept ascii or hex data over something as basic as telnet. In such a case you specify IP, port and a simple string, like "MVUP" for Volume Up on a Marantz AVP/AVR. Following the same limitations it's possible to specify the port of an http listener, but then you're limited still to some string, so in essence a URL as a browser would pass a site.

Anything more complex would likely require a 2-way module tailored for the device the MX-5000 is trying to control - and that's not something anyone outside URC can develop.

I'm not saying it's recommended or needed for anyone else, but to work with what I have, it looks like a necessity.

from harmony-api.

This would conceivably also work as PUT. Cross-referencing a number of devices that can apparently be controlled with this remote, many Yamaha (for example) seem to require PUT, which means that the remote must work as its setup software includes a suite of IP commands for those products.

from harmony-api.

¯(°_o)/¯ you could just fork it and change them to all GETs and it would work for you.

from harmony-api.

That's all I needed to hear. :) No desire for you to incorporate this in the master whatsoever, I just need something "that works" basically to bridge the HH to my URC remote.

from harmony-api.