10. Servidores Web¶
Os capítulos de redes colocaram a câmera na rede e lhe deram sockets para se comunicar (Redes). E agora? A maioria das aplicações de câmera se resume a duas coisas – expor ao mundo o que a câmera vê e reagir ao que outras coisas na rede dizem. O HTTP é como essa conversa acontece, e funciona em ambas as direções:
Como servidor, a câmera responde a requisições de telefones, navegadores e outros dispositivos na rede. O framework
microdoté o servidor da câmera.Como cliente, a câmera busca serviços na nuvem para fazer upload, buscar ou coordenar. O módulo
requestsé o cliente da câmera.
Ao longo dos próximos 14 capítulos, construiremos uma aplicação de câmera em funcionamento que exercita ambos.
Uma câmera de quintal com gatilho de movimento fica em um poste no quintal, vê o que está acontecendo e avisa o proprietário sobre qualquer coisa interessante. Faremos a câmera crescer de um servidor de uma única rota “estou vivo” para algo entregável: prévia ao vivo no telefone do proprietário, um painel com um controle deslizante de limiar e um log de eventos, notificações push quando o movimento dispara, login, HTTPS e um arquivo na nuvem de cada quadro disparado.
Cada capítulo adiciona uma funcionalidade. Os exemplos de código pressupõem que os capítulos anteriores estão em vigor – não recolamos o script inteiro toda vez.
- 10.1. Seu primeiro endpoint
- 10.2. Retornando um snapshot
- 10.3. Transmissão ao vivo – um espectador
- 10.4. Compartilhando um loop de captura entre espectadores
- 10.5. Uma API de controle para a câmera
- 10.6. Construindo o painel
- 10.7. Enviando eventos para o painel
- 10.8. Controle bidirecional com WebSockets
- 10.9. Autenticação para clientes programáticos
- 10.10. Login para o painel
- 10.11. HTTPS – criptografia de transporte para o servidor
- 10.12. CORS e CSRF
- 10.13. Enviando quadros disparados para a nuvem
- 10.14. Conclusão