10. Webserver¶
Die Netzwerk-Kapitel haben die Kamera ins Netzwerk gebracht und ihr Sockets zur Kommunikation gegeben (Netzwerke). Was nun? Die meisten Kameraanwendungen laufen auf zwei Dinge hinaus – der Welt zeigen, was die Kamera sieht und auf das reagieren, was andere Dinge im Netzwerk sagen. HTTP ist die Art, wie diese Konversation stattfindet, und es funktioniert in beide Richtungen:
Als Server beantwortet die Kamera Anfragen von Telefonen, Browsern und anderen Geräten im Netzwerk. Das Framework
microdotist der Server der Kamera.Als Client wendet sich die Kamera an Cloud-Dienste, um hochzuladen, abzurufen oder zu koordinieren. Das Modul
requestsist der Client der Kamera.
In den nächsten 14 Kapiteln bauen wir eine laufende Kameraanwendung, die beides nutzt.
Eine Bewegungsauslöser-Kamera für den Hinterhof sitzt auf einem Pfosten im Garten, sieht, was vor sich geht, und teilt dem Besitzer alles Interessante mit. Wir lassen die Kamera von einem „Ich lebe“-Server mit einer einzigen Route zu etwas Auslieferbarem heranwachsen: Live-Vorschau auf das Telefon des Besitzers, ein Dashboard mit Schwellenwert-Schieberegler und Ereignisprotokoll, Push-Benachrichtigungen bei ausgelöster Bewegung, Login, HTTPS und ein Cloud-Archiv jedes ausgelösten Einzelbilds.
Jedes Kapitel fügt ein Feature hinzu. Die Codebeispiele setzen voraus, dass die früheren Kapitel umgesetzt sind – wir fügen nicht jedes Mal das gesamte Skript erneut ein.
- 10.1. Ihr erster Endpunkt
- 10.2. Einen Schnappschuss zurückgeben
- 10.3. Live-Streaming – ein Betrachter
- 10.4. Eine Erfassungsschleife über mehrere Betrachter hinweg teilen
- 10.5. Eine Steuerungs-API für die Kamera
- 10.6. Das Dashboard erstellen
- 10.7. Ereignisse an das Dashboard senden
- 10.8. Zweiwege-Steuerung mit WebSockets
- 10.9. Authentifizierung für programmatische Clients
- 10.10. Anmeldung für das Dashboard
- 10.11. HTTPS – Transportverschlüsselung für den Server
- 10.12. CORS und CSRF
- 10.13. Ausgelöste Einzelbilder in die Cloud hochladen
- 10.14. Zusammenfassung