Feature Request: support for using http API instead of serial

[martinj]

Have you considered adding support for using the HTTP API instead of connecting over serial. Did a quick peek at the code and the serial API looks identical to the HTTP one.

Would be nice to use it without any cables.

[badvision]

I'm not sure if the HTTP API uses checksum on the messages. That wouldn't change things much but would make some difference.

[badvision]

Upon further inspection, the HTTP API is very similar.. kind of... except that status commands return right away whereas other commands return a response size and the response itself is collected via another call. Very odd behavior but I'm sure it's meant to support asynchronous activity somehow. The only downside to this is you might get some unusual behavior if you are running two clients at the same time. That alone could be a deal-breaker to support more advanced functionality such as retrieving error messages and the like. Otherwise for general status updates and sending no-response gcodes it would be pretty feasible to use the web client.

[badvision]

However, Telnet and/or SSH support seems to be the way to go. It behaves exactly like UART and doesn't interfere with the web UI.

[badvision]

FWIW, an implementation using sockets is in my fork -- it only uses this if a raspberry pi is not detected but it seems to work pretty well. I implemented it because it really helps testing/iteration of UX stuff from my dev machine without having to deploy/test as often on a Pi.