We're talking lighter than minihttp and shizaru - instead of a separate process on an OS, you'd use library that allows your firmware to respond to http requests, but that still allows you to run all the relatively complex UI/UX code on the user's computer or phone, with the microcontroller only handling the physical functionality; and reduces the need to have and manage more physical buttons/lights/screens/etc on the device itself; but you can do that without writing a separate app to generate some custom command&control messages - as in the grandparent post example of encoding RGB light control in an UDP packet, it would probably need three times the amount of code both on sending and receiving side compared to a http-based rgb control, which can probably be done in ten or so lines of your own code.
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.
