During the project several of the students asked "Why are we using REST calls to pass/fetch data? Couldn't we set up a socket connection instead?" There's a few reasons for this, but first we should at least talk about the pros and cons of using REST.

On the pros side, it's quite easy to support treating all our networking like they are web requests.  There are numerous libraries in place to handle all the data transfer, minimal networking involved, and the actions are well understood and documented.  On top of this, testing is made easier as we could easily try many of our API calls with nothing more than a smartphone and it's web browser.

Using a shared networking standard also makes integration with other apps easier.  Early on there was a lot of discussion about building additional stations out of computers, projectors, raspberry pi's, etc.  By using such a ubiquitous standard as web requests, any software and hardware we wanted to use would already be compatible.  If could fetch a webpage from the internet then it could be wired into our game.

There are a couple cons though.  The largest of these is the asynchronous "pull" nature of REST.  Data can only be requested, it can't be pushed.  This means if a change happens on the server, then there's no immediate way to tell the clients about it.  Instead, we had to design into the scanners a regular "keepalive" check.  This was a timer which would contact the server every half second to see if there were any updates the scanner cared about.

This naturally leads to a couple more issues.  Firstly, this meant we had to do more work keeping track of our game states and player states, as different scanners would call in at different times.  There was also no guarantee of when a scanner would update next, so it was possible for scanners to receive updates at different times.  There were several instances during play where scanners temporarily lost network connection and missed updates like voting for upwards of 4-5 seconds.

Theoretically this also wasted a bit of network bandwidth and put stress on the server, as every scanner was pinging home twice a second whether there were updates or not.  In reality though we never saw any degradation with just 8 scanners, and a stress test using Postman showed the server could process at least several hundred requests/second, so the 16-25 requests we were throwing at it weren't really an issue.

Overall though, the biggest reason we went with REST was to give the students a real-life experience using it.  The vast majority of programming work out there today is web-based; it's something they'll be going into anyway.  A project like this taught them all how to build APIs, make GET/POST requests, and move data, while being a lot more fun than simply building out a forum board or accounting application :)