Oh, that's pretty neat. Basically trimming the server down to the routing itself.
1. accept HTTP
2. check for valid endpoint
3. if yes, do thing and exit
4. if no, 'error'
Client side has fancy UI for essentially templating per-HTTP request or command sent to the device.
I guess the only issue I see is you'd need some sort of firewalling or security. Otherwise any rando could fire HTTP requests at the thing and make it do stuff.
How would you structure this on the device's side? If a webserver's too big, then I imagine an init system is also too big.
You generally don't structure it as having a webserver, you'd structure it as an app (you run a single app on the device, there's no separate OS involved) that can react to HTTP requests - i.e. my mental model is that you don't run a webserver on the device, but instead that the device becomes a webserver.
You can structure the on-device app as 'slaved' to the web requests, where it simply waits for requests in a loop and only does stuff in response to a request - for example, take a measurement from some sensors and send them back with some surrounding HTML.
Authentication/authorization is an issue, but it has all the same issues and solutions as webapps - login+session cookies; or whitelisting IP ranges; or TLS client certificates; etc.
I guess the only issue I see is you'd need some sort of firewalling or security. Otherwise any rando could fire HTTP requests at the thing and make it do stuff.
How would you structure this on the device's side? If a webserver's too big, then I imagine an init system is also too big.