MODELO MENTAL
Cliente pede; servidor atende — mas nenhum deles precisa ser uma única máquina.
“Cliente” e “servidor” descrevem o papel exercido em uma interação. Um navegador é cliente de uma API. A própria API pode agir como cliente de um banco, de um serviço de pagamentos ou de outra API.
Laboratório visual · Da troca simples à infraestrutura real
Alterne o nível de detalhe sem perder o modelo básico.
Modelo básico: cliente inicia a troca e servidor responde. Os nomes descrevem responsabilidades, não o tamanho ou o endereço da máquina.
DIVISÃO DE TRABALHO
Boa arquitetura separa experiência local de autoridade sobre o negócio.
No cliente
Interface, interação imediata, acessibilidade, validação para ajudar a pessoa, estado visual, cache local controlado e apresentação dos dados.
No servidor
Validação confiável, autenticação, autorização, regras de negócio, transações, persistência, auditoria, limitação de abuso e integração segura.
No contrato
URLs, métodos, formatos, versões, erros, paginação, idempotência, limites e expectativas de compatibilidade entre as partes.
Validar um campo no navegador melhora a experiência, mas o usuário controla o cliente e pode alterar JavaScript, forjar requisições ou chamar a API diretamente. Por isso, toda regra que protege dados, dinheiro ou permissão precisa ser aplicada novamente no servidor.
| Decisão | Cliente | Servidor | Por quê? |
|---|---|---|---|
| Campo obrigatório | Avisa antes do envio. | Rejeita se ausente. | Experiência local não cria confiança. |
| Preço final | Exibe uma estimativa. | Calcula com regra oficial. | O valor não pode depender de dados manipuláveis. |
| Permissão | Oculta ações não disponíveis. | Autoriza cada operação. | Esconder botão não impede chamada direta. |
| Formatação | Adapta idioma e layout. | Entrega dado estável e metadados. | Apresentação varia por dispositivo e pessoa. |
UMA URL, MUITAS CAMADAS
A resposta pode atravessar intermediários antes de chegar à aplicação.
- Descoberta: DNS converte o hostname em um endereço associado à CDN, proxy ou origem.
- Canal: cliente estabelece TCP ou QUIC e, no HTTPS, negocia TLS.
- Intermediário: CDN ou proxy pode responder do cache, aplicar limites, terminar TLS ou encaminhar.
- Balanceamento: uma instância saudável é escolhida entre várias réplicas.
- Aplicação: rota, autenticação, validação e regra de negócio são executadas.
- Dados: a aplicação consulta bancos, caches, filas ou serviços externos.
- Resposta: o caminho retorna com status, headers e conteúdo; intermediários podem armazenar representações autorizadas.
ESTADO E CONCORRÊNCIA
Requisições independentes podem disputar o mesmo dado.
HTTP permite tratar cada requisição com contexto suficiente, mas a aplicação pode manter estado em sessão, banco ou cache. Quando muitos clientes atuam juntos, aparecem corridas: dois usuários compram o último item ou atualizam a mesma versão de um documento.
Identidade
Cookies, tokens ou certificados ajudam a reconhecer o chamador; autorização decide o que ele pode fazer.
Consistência
Transações, bloqueios, versões e restrições preservam invariantes quando operações concorrem.
Repetição
Timeouts geram retries. Operações críticas precisam ser idempotentes ou usar chaves de idempotência.
VARIAÇÕES DO MODELO
“Cliente-servidor” continua válido em SPA, mobile e microsserviços.
| Cenário | Cliente | Servidor | Observação |
|---|---|---|---|
| Página renderizada no servidor | Navegador pede documentos e recursos. | Produz HTML pronto para navegação. | Interações posteriores ainda podem chamar APIs. |
| SPA | JavaScript gerencia interface e rotas locais. | Expõe dados e operações via API. | Não transfere autoridade de negócio para o browser. |
| Aplicativo mobile | App instalado consome endpoints. | Compartilha regras e dados com outros clientes. | Versões antigas do app podem permanecer em uso. |
| Microsserviços | Um serviço chama outro. | O serviço chamado atende o contrato. | A mesma aplicação assume papéis diferentes em chamadas diferentes. |
| Peer-to-peer | Cada participante pode oferecer e consumir. | Os papéis se alternam entre pares. | Não significa ausência de protocolos ou coordenação. |
PARE E PENSE
A interface escondeu o botão “Excluir usuário” para quem não é administrador. A API está protegida?
Pense no que aconteceria se alguém reproduzisse a requisição manualmente.
CONTINUE EXPLORANDO
Referências e itens adicionais de estudo
Referências técnicas
Padrões que definem os papéis e a troca Web.
- RFC 9110 · HTTP Semantics — cliente, servidor, origem, intermediários e mensagens.
- WHATWG · Fetch Standard — requisições, respostas e integração do navegador com a rede.
- WHATWG · HTML Living Standard — navegação, documentos e plataforma Web.
- RFC 9111 · HTTP Caching — cache em clientes e intermediários.
Itens adicionais de estudo
Atividades de arquitetura.
- Escolha uma compra on-line e divida cada responsabilidade entre cliente, servidor e contrato.
- No DevTools, identifique requests atendidos por memória, disco, service worker, CDN e origem.
- Desenhe a mesma aplicação como uma instância e como três réplicas atrás de balanceador.
- Pesquise optimistic concurrency e explique como um ETag pode evitar sobrescrita perdida.
- Liste quais dados jamais deveriam ser confiados apenas ao JavaScript do navegador.