APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Cache pode reduzir latência e carga, mas precisa de uma política coerente com conteúdo e audiência. no-cache permite armazenamento sujeito a validação antes da reutilização; no-store instrui a cache a não guardar, sem garantir por si só toda a privacidade do sistema. private distingue cache partilhada de cache privada. Nenhuma destas diretivas deve ser usada como substituto de autorização ou encriptação. Ao diagnosticar uma resposta antiga, recolhe headers e identifica a camada que a serviu. Uma configuração correta no serviço pode ser alterada por um proxy, pelo que a observação deve atravessar o caminho efetivo.
Aplicação guiada
Num cenário fictício, um relatório de posições aparece no cliente errado depois de ser servido por cache partilhada. Suspende a reutilização indevida, preserva evidência e revê a política e a separação de respostas por identidade. Na listagem de coleções, define paginação e estabilidade da ordenação. Um cursor não é automaticamente um snapshot consistente, nem um token de autorização. A orientação Google AIP 158 ilustra tokens opacos para continuar listagem, mantendo autorização em cada pedido. Documenta o que acontece quando entram novos registos entre páginas, quais os filtros que devem permanecer iguais e quando o cursor expira. Uma página curta não prova fim se existir continuação no contrato.
Cache e cursor são mecanismos de entrega; não transferem permissões de um utilizador para outro.
Armadilhas comuns
No-cache como não guardar; private como encriptação; cursor como autorização; página curta como fim universal.
Tópicos relacionados: Recursos e contratos de API · Pedidos e resultados · Concorrência e repetição
Valida audiência, frescura e continuidade de acordo com o contrato.
Referência: RFC9111 HTTP Caching · HTTP semantics RFC9110; OpenAPI3.2.1; selected primary standards and provider contracts consulted2026-09-30