>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.
I built a door system intended for a small office with a Pi, some sparkfun components, and Go. My code is here: https://github.com/GauntletWizard/vnw ; If anyone wants a more detailed explaination, I'll try to write one up.
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.