10. Web Servers¶

The networking chapters got the cam onto the network and gave it sockets to talk through (Networking). What now? Most camera applications boil down to two things – expose what the cam sees to the world and react to what other things on the network say. HTTP is how that conversation happens, and it works in both directions:

As a server, the cam answers requests from phones, browsers, and other devices on the network. The microdot framework is the cam’s server.
As a client, the cam reaches out to cloud services to upload, fetch, or coordinate. The requests module is the cam’s client.

Across the next 14 chapters we’ll build one running camera application that exercises both.

A backyard motion-trigger cam sits on a pole in the yard, sees what’s going on, and tells the owner about anything interesting. We’ll grow the cam from a one-route “I’m alive” server into a shippable thing: live preview to the owner’s phone, a dashboard with a threshold slider and an event log, push notifications when motion fires, login, HTTPS, and a cloud archive of every triggered frame.

Each chapter adds one feature. Code samples assume the earlier chapters are in place – we don’t re-paste the whole script every time.

The phone or laptop talks to the cam over HTTPS for the dashboard, SSE events, and WebSocket commands; the cam talks out to a cloud archive over HTTPS POST.