>For the Raspberry Pi server we decided to write some Python using Tornado and instead of using an HTTP like API - HTTP and APIs built on it using REST etc are in my opinion often used too often when plain old sockets will do the job! - we decided to negotiate a socket using WebSockets and then communicate messages as small as possible over that socket so that the latency was negligible.
Not that it matters much which tool you use for a job like this, but this part doesn't really make sense. A WebSocket handshake is at least as big as this sort of REST request would have been, and if you wanted to keep everyone connected a basic TCP socket would work even better. They write how they had to implement a heartbeat on top of WebSockets, which seems like more work than the message framing on a TCP socket would have been.
I did a similar project, using Node.js to implement it with REST.
The advantage of that is I can create a CA with OpenSSL and sign a certificate for the server and one for the Raspberry Pi, and that way you can check if the other end is presenting a certificate signed by the same CA.
It has a streaming HTTP mode, where the connection stays open and data comes in as the clients send them. It works very well for remotely opening my house doors.
Not that it matters much which tool you use for a job like this, but this part doesn't really make sense. A WebSocket handshake is at least as big as this sort of REST request would have been, and if you wanted to keep everyone connected a basic TCP socket would work even better. They write how they had to implement a heartbeat on top of WebSockets, which seems like more work than the message framing on a TCP socket would have been.
Neat project just the same, though.