10. Serveurs web

Les chapitres consacrés au réseau ont connecté la caméra au réseau et lui ont donné des sockets pour communiquer (Réseau). Et maintenant ? La plupart des applications de caméra se résument à deux choses – exposer au monde ce que voit la caméra et réagir à ce que disent les autres équipements du réseau. HTTP est la manière dont cette conversation a lieu, et elle fonctionne dans les deux sens :

  • En tant que serveur, la caméra répond aux requêtes des téléphones, des navigateurs et des autres appareils du réseau. Le framework microdot est le serveur de la caméra.

  • En tant que client, la caméra contacte des services cloud pour téléverser, récupérer ou coordonner. Le module requests est le client de la caméra.

Au fil des 14 chapitres suivants, nous allons construire une seule application de caméra fonctionnelle qui exerce les deux rôles.

Une caméra de détection de mouvement de jardin est installée sur un poteau dans la cour, observe ce qui se passe et avertit le propriétaire de tout ce qui est intéressant. Nous ferons évoluer la caméra d’un serveur « je suis vivant » à une seule route vers un produit livrable : aperçu en direct sur le téléphone du propriétaire, un tableau de bord avec un curseur de seuil et un journal d’événements, des notifications push lorsqu’un mouvement se déclenche, l’authentification, HTTPS et une archive cloud de chaque trame déclenchée.

Chaque chapitre ajoute une seule fonctionnalité. Les exemples de code supposent que les chapitres précédents sont en place – nous ne recollons pas l’intégralité du script à chaque fois.

Le téléphone ou l'ordinateur portable communique avec la caméra en HTTPS pour le tableau de bord, les événements SSE et les commandes WebSocket ; la caméra communique vers une archive cloud via des POST HTTPS.