10. Serwery WWW¶
Rozdziały o sieci doprowadziły kamerę do sieci i dały jej gniazda do komunikacji (Sieci). Co teraz? Większość aplikacji kamerowych sprowadza się do dwóch rzeczy – udostępnienia światu tego, co widzi kamera oraz reagowania na to, co mówią inne urządzenia w sieci. HTTP jest sposobem, w jaki odbywa się ta rozmowa, i działa w obu kierunkach:
Jako serwer kamera odpowiada na żądania od telefonów, przeglądarek i innych urządzeń w sieci. Framework
microdotjest serwerem kamery.Jako klient kamera sięga do usług chmurowych, aby przesyłać, pobierać lub koordynować dane. Moduł
requestsjest klientem kamery.
W ciągu kolejnych 14 rozdziałów zbudujemy jedną działającą aplikację kamerową, która wykorzystuje oba te tryby.
Kamera z wyzwalaczem ruchu na podwórku siedzi na słupie na podwórku, widzi, co się dzieje, i informuje właściciela o wszystkim, co interesujące. Rozwiniemy kamerę z jednotrasowego serwera „żyję” w gotowy do wdrożenia produkt: podgląd na żywo na telefonie właściciela, pulpit z suwakiem progu i dziennikiem zdarzeń, powiadomienia push przy wykryciu ruchu, logowanie, HTTPS oraz archiwum w chmurze każdej wyzwolonej ramki.
Każdy rozdział dodaje jedną funkcję. Przykłady kodu zakładają, że wcześniejsze rozdziały są już zaimplementowane – nie wklejamy za każdym razem całego skryptu od nowa.
- 10.1. Twój pierwszy punkt końcowy
- 10.2. Zwracanie zrzutu obrazu
- 10.3. Transmisja na żywo – jeden widz
- 10.4. Współdzielenie jednej pętli przechwytywania między widzami
- 10.5. API sterujące dla kamery
- 10.6. Budowanie panelu
- 10.7. Wypychanie zdarzeń do panelu
- 10.8. Dwukierunkowe sterowanie za pomocą WebSockets
- 10.9. Uwierzytelnianie dla klientow programowych
- 10.10. Logowanie do panelu
- 10.11. HTTPS – szyfrowanie transportu dla serwera
- 10.12. CORS i CSRF
- 10.13. Przesyłanie wyzwolonych ramek do chmury
- 10.14. Podsumowanie