Protocolo

HTTP

Diferente de TCP, que entrega um fluxo de bytes, HTTP define métodos, campos, status e representações no nível de aplicação. A semântica atual está em RFC 9110; HTTP/1.1 usa RFC 9112 sobre TCP, HTTP/2 usa RFC 9113 e HTTP/3 usa RFC 9114 sobre QUIC. A adoção é barata por ampla compatibilidade, mas exige servidor, autenticação e TLS; sem isso, APIs de casa inteligente ficam expostas a interceptação, abuso e comandos não autorizados.

↗ Wikidata · Q8777

📖Definição aprofundada

HTTP é o protocolo de aplicação usado para trocar mensagens entre clientes, servidores, proxies e gateways. Sua unidade central é a requisição seguida de uma resposta. A requisição possui método, alvo, campos e conteúdo opcional. A resposta possui código de status, campos e conteúdo. A semântica é independente da versão de transporte. RFC 9110, publicada em 2022, define métodos, status, cache, autenticação, conteúdo e regras comuns. HTTP/1.1 é especificado em RFC 9112 e usa mensagens textuais sobre conexões TCP. HTTP/2, RFC 9113, introduz enquadramento binário, multiplexação de streams e compressão de cabeçalhos sobre uma conexão, normalmente protegida por TLS. HTTP/3, RFC 9114, leva a mesma semântica para QUIC sobre UDP e reduz o bloqueio entre streams causado por perda no transporte TCP. Em casa inteligente, HTTP aparece em APIs REST de hubs, câmeras, inversores, medidores, Home Assistant, Node-RED, gateways e serviços cloud. Um cliente pode executar `GET /api/states` para ler, `POST /api/services/light/turn_on` para comandar ou receber um arquivo de firmware. O protocolo não define o significado do recurso. O contrato da API faz. JSON é comum, mas HTTP também transporta CBOR, imagens, vídeo, HTML, arquivos e Protocol Buffers. O custo de adoção é baixo porque sistemas operacionais, navegadores, linguagens, proxies e ferramentas já implementam. Essa conveniência traz dependências. O servidor precisa de TLS, autenticação, autorização, limites, logs e atualização. Uma API HTTP aberta numa VLAN não é segura apenas por estar na rede local. Dispositivos infectados podem alcançar. HTTPS protege confidencialidade e integridade em trânsito. A autenticação por token, certificado ou sessão identifica. A autorização decide se o usuário pode destravar uma porta. Métodos têm propriedades. GET, HEAD, PUT e DELETE são definidos como idempotentes em sua semântica; POST não é necessariamente. Implementações podem violar. Uma API não deve usar GET para ligar relé porque caches, prefetch e crawlers podem repetir. Status precisam ser corretos: 200 sucesso, 201 criação, 202 aceitação assíncrona, 204 sem conteúdo, 400 pedido inválido, 401 autenticação necessária, 403 proibido, 404 ausente, 409 conflito, 429 limite e 5xx falha do servidor. O cliente não deve tratar qualquer 2xx como confirmação física sem contrato. Um 202 pode apenas enfileirar. Timeouts são essenciais. Sem eles, automações ficam presas. Retentativas precisam considerar idempotência. Cabeçalhos `ETag` e `If-Match` ajudam controle de concorrência. Cache reduz carga, mas estados de fechadura e presença exigem política. `Cache-Control: no-store` pode ser apropriado. CORS controla navegadores, não é autenticação. Cookies precisam de Secure, HttpOnly e SameSite. Proxies alteram cabeçalhos. A confiança em `X-Forwarded-For` deve ser limitada. Para eventos em tempo real, WebSocket ou SSE podem ser melhores que polling. HTTP continua no handshake e na gestão. O protocolo é maduro e interoperável, mas a qualidade depende do contrato e da implementação.

Arquitetura e Funcionamento

Métodos e recursos

Métodos expressam a intenção sobre um recurso. GET recupera representação e deve ser seguro; HEAD obtém metadados; POST processa ou cria; PUT substitui ou define; PATCH modifica parcialmente; DELETE remove; OPTIONS descreve opções. Uma API de iluminação pode usar `PUT /lights/1/state` com `{"on":true}` para estabelecer estado. Um endpoint `POST /toggle` é mais difícil de repetir após timeout. O desenho deve preferir operações absolutas quando automações podem retentar. URIs identificam recursos. Nomes estáveis evitam acoplamento à implementação. Query strings filtram e paginam. Dados sensíveis não devem ficar na URL porque aparecem em logs. O corpo precisa de Content-Type, como `application/json`. O servidor valida tamanho e schema. A negociação por Accept permite formatos. O cliente deve tolerar campos novos. A documentação OpenAPI descreve, mas não substitui testes.

Conexões, versões e multiplexação

HTTP/1.1 reutiliza conexões persistentes, mas o pipelining teve adoção limitada. Navegadores abrem várias conexões. HTTP/2 multiplexa múltiplos streams numa conexão TCP, comprime cabeçalhos com HPACK e usa prioridades e flow control. Uma perda TCP pode atrasar todos os streams. HTTP/3 usa QUIC, TLS 1.3 integrado e streams independentes. Uma perda de pacote que afeta um stream não bloqueia a entrega dos demais no mesmo nível. A escolha costuma ser feita pelo servidor, cliente e proxy por ALPN. Um dispositivo embarcado pode suportar apenas HTTP/1.1. Isso não impede uma API correta. HTTP/3 pode exigir UDP 443 liberado; redes que bloqueiam fazem fallback. Reverse proxies precisam suportar. O backend pode falar HTTP/1.1 mesmo que o cliente use HTTP/3 na borda. O operador deve medir latência e CPU. Versão nova não corrige API ruim.

Segurança e identidade

HTTPS é HTTP sobre um transporte protegido. O cliente valida certificado e nome. Desativar verificação para “resolver” certificado local abre ataque. Em LAN, use CA privada, certificado ACME por DNS ou proxy confiável. Tokens Bearer precisam de TLS porque quem copia pode usar. OAuth 2.0 e OpenID Connect atendem cenários de autorização e identidade. API keys identificam aplicação, não usuário. mTLS autentica cliente e servidor, útil entre gateways. A autorização precisa ocorrer por recurso. Um token de leitura não deve destravar. Logs não registram Authorization, cookies nem corpos com códigos. Rate limiting reduz abuso. CSRF importa quando cookies autenticam. CORS não impede chamadas de dispositivos não navegadores. Firmware deve atualizar bibliotecas. Request smuggling e parsing divergente entre proxy e backend são riscos. Manter componentes alinhados e normalizar. HTTP/2 e HTTP/3 possuem vulnerabilidades próprias de implementação. Segurança depende da pilha inteira.

Cache, concorrência e confiabilidade

Cache é parte da semântica. `Cache-Control`, `Expires`, `ETag`, `Last-Modified`, `If-None-Match` e `If-Match` controlam. Para catálogo de dispositivos, cache economiza. Para estado crítico, pode gerar dado obsoleto. Um `ETag` permite atualização condicional: o cliente lê versão A e envia `If-Match: A`; se outro mudou, recebe 412. Isso evita sobrescrever. Idempotency-Key protege POST contra duplicação quando o servidor implementa. Timeouts devem existir para conexão e resposta. Retry usa backoff e jitter. Respeitar `Retry-After` em 429/503. Circuit breaker evita cascata. O cliente precisa distinguir falha de rede de rejeição. Um timeout após comando deixa resultado incerto; consultar estado e usar chave. O servidor deve responder rápido ou criar job 202. Operações longas não ficam numa conexão indefinida. Observabilidade usa `traceparent`, request ID, status e latência, sem dados sensíveis.

Análise Técnica

✓ Vantagens

Ecossistema universal: bibliotecas, navegadores, proxies, gateways, ferramentas e observabilidade estão disponíveis em praticamente qualquer plataforma, reduzindo custo de integração.
Semântica padronizada de métodos, status, cache e representação facilita contratos entre Home Assistant, aplicativos, hubs, clouds e serviços de terceiros.
Funciona sobre várias gerações de transporte: HTTP/1.1, HTTP/2 e HTTP/3 preservam o modelo de aplicação e permitem evolução sem redesenhar todos os recursos.
Integra segurança madura por TLS, certificados, OAuth, OIDC, mTLS e políticas de gateway, desde que configuradas corretamente.
É adequado a APIs de configuração, comandos, consulta, firmware e administração, podendo coexistir com WebSocket, SSE, MQTT e brokers para eventos.

✗ Desvantagens

O protocolo não fornece autenticação nem autorização por padrão; HTTP sem TLS e endpoints locais abertos expõem dados e comandos.
Cabeçalhos e mensagens têm overhead maior que protocolos binários compactos em dispositivos restritos; CoAP ou MQTT podem consumir menos.
Modelo requisição-resposta não entrega eventos espontâneos sozinho; polling aumenta tráfego e WebSocket/SSE adicionam conexões persistentes.
Caches, proxies, retries e métodos mal usados podem duplicar ações ou servir estado obsoleto; o contrato precisa ser desenhado com idempotência.
A ampla extensibilidade cria diferenças entre implementações e riscos de parsing, headers confiáveis, CORS, cookies e configuração de proxy.

💡 Cenário Prático: HTTP em uma arquitetura local de casa inteligente

Uma implantação robusta coloca dispositivos numa VLAN IoT, evita expor APIs diretamente à internet e usa um gateway ou reverse proxy para acesso controlado. Home Assistant pode oferecer HTTPS por proxy. Integrações locais usam tokens de longa duração apenas em cofre e com escopo quando possível. Para ler sensores, GET com timeout de 3–10 s pode ser suficiente. Para comandos, usar endpoint documentado, estado absoluto e chave de idempotência quando disponível. O sistema confirma pelo estado do dispositivo, não só pelo 200. Eventos de alta frequência passam por WebSocket, MQTT ou broker. Logs registram rota, status e latência, sem token. Certificados são renovados. O roteador impede acesso da VLAN IoT à rede administrativa, liberando apenas DNS, NTP e endpoints necessários. Um gateway pode traduzir HTTP proprietário para entidades. A tradução precisa preservar unidade, disponibilidade e erros. Em câmera, HTTP gerencia configuração; RTSP/WebRTC transporta vídeo. Em Matter, HTTP pode existir na cloud do fabricante, mas o controle local usa Matter. As camadas são complementares.