## Continuando...

Como eu ia dizendo, o header "Cache-Control" contém uma instrução do servidor para o cliente, indicando como o cliente deve manter aquele recurso em cache. Por ser uma instrução que o servidor envia na resposta de uma requisição, isso deve ser configurado no servidor. O cliente pode apenas seguir a recomendação dada pelo servidor.
O header "etag" é usado por alguns servidores e funciona como um hash do conteúdo da resposta. Se o conteúdo do recurso muda, a "etag" muda. Quando um cliente envia uma requisição e a etag é igual à que está no cache, o cliente usa o cache. Isso não evita o tráfego, mas ajuda na UX, proporcionando um carregamento mais rápido, principalmente em redes lentas.
A requisição tem headers, um método e um corpo. Esquecendo a parte mais complexa relacionada a métodos, podemos focar em GET e POST.
GET é usado pelo navegador quando você acessa um site. A requisição que obtém o HTML é feita pelo navegador com esse método. O servidor entende e envia o conteúdo do HTML no corpo da resposta. Pensando em um sistema de cadastro, que poderia ser para receber novidades sobre a Contabilizei por e-mail, para enviar os dados digitados pelo usuário para o servidor, o método POST seria usado. As diferenças principais são: não é possível fazer cache das respostas a requisições POST (porque o propósito é enviar informações para o servidor) e os dados digitados não ficam visíveis na URL. A segunda característica é boa para formulários de login, por exemplo. A senha do usuário não fica na URL. Para interceptar e acessar essa informação, você teria que olhar o corpo da requisição, mas caso a conexão seja feita por HTTPS, o corpo é criptografado e fica ofuscado para quem interceptar, podendo ser lido apenas pelo servidor. Fica a dica: pesquisem sobre HTTPS e por que é tão importante utilizá-lo.

## REST

Considerando que o método GET significa que o cliente deseja obter informações e o POST, que a intenção é enviar, podemos falar sobre REST. Usando o conjunto: URL, headers e corpo, é possível fazer comunicação entre navegador e servidor (agora vamos focar mais em front-end e back-end) de uma forma muito flexível. Toda essa flexibilidade pode fazer com que pontos diferentes da aplicação se comuniquem de forma diferente e um desenvolvedor ou desenvolvedora que mudasse de equipe teria que aprender um novo padrão para cada sistema diferente que fosse desenvolver. Para resolver isso, foi criado o REST. REST não é uma biblioteca, nem um framework, nem um protocolo, mas sim um padrão de modelagem de comunicação usando HTTP. É importante ter isso em mente, que no fim não existe uma "requisição REST" ou um "endpoint REST". É tudo HTTP puro. O REST define como as URLs devem ser projetadas e como o front-end deve indicar a intenção dele (pode ser ler um recurso, inserir, remover ou alterar). Podemos chamar esse conjunto de URLs, métodos e formato dos dados enviados e recebidos de API. O REST é um padrão muito popular, mas pouco usado da forma que o autor propôs, porque as restrições impostas por esse padrão nem sempre fazem com que a API de um sistema seja mais fácil de entender ou de usar, então no dia a dia costumamos seguir alguns princípios do REST, mas não todos.
Existem outras formas de organizar a comunicação entre back-end e front-end e usamos o padrão back-end for front-end (BFF) na plataforma e em outras aplicações importantes. De forma resumida, o modelo BFF também é HTTP sem nenhum framework ou biblioteca. O padrão REST é bom para APIs que serão consumidas por clientes diferentes (pode ser um app de celular, uma página web, outro servidor, etc). O ganho com REST é de ter mais facilidade de documentar, perdendo em eficiência. O BFF, por outro lado, foca em garantir que o tráfego e as quantidades de requisições sejam os menores possíveis com o prejuízo de tornar aquela API completamente específica para um determinado tipo de cliente. No nosso caso, a Plataforma Web tem seu BFF, o app mobile pode ter o seu (que obrigatoriamente seria outro), um parceiro da contabilizei pode ter seu BFF específico também.
Recomendo uma leitura sobre GraphQL, para expandir o conhecimento. O GraphQL também é baseado em HTTP, mas não é apenas um padrão de modelagem. O dispositivo que faz o papel de cliente precisa ter a capacidade de interpretar a comunicação HTTP como GraphQL e o servidor também. Na prática, isso significa instalar uma biblioteca de JS no front para montar as queries e uma bibiliteca no back-end para receber e interpretar as queries. No final, continua sendo HTTP, porém o cliente e o servidor precisam de bibliotecas adicionais para se comuicar.

## Cookies

Cookies são strings que ficam salvas no navegador. Dependendo da política de compartilhamento de cookies, o navegador vai enviar determinados cookies automaticamente junto das requisições. Cada cookie tem um nome, um conteúdo e outras propriedades que determinam a política de compartilhamento. Essa política é definida por propriedades de cada cookie, pelos domínios de cada requisição e pelo tipo de conexão (se usa HTTPS ou não).
Podemos observar os cookies por dois pontos de vista: podem ser uma forma de armazenar informações no navegador e podem ser uma forma de ter um funcionamento stateful na web, que é stateless.
Sobre as formas de armazenar informações no navegador, existem várias opções, cada uma com suas características. Por exemplo, temos SessionStorage, LocalStorage, IndexedDB, Cookies... A grande diferença é que cookies podem ser armazenados por JavaScript ou pelo servidor, enquanto os outros precisam do JavaScript. O servidor não tem acesso direto a armazenar um cookie, mas por padrão, se a resposta de uma requisição contiver um header "Set-Cookie", o navegador armazena. Isso é importantíssimo para a Web, porque apesar dos navegadores terem bom suporte a JavaScript, páginas web deveriam funcionar sem depender disso.
Sobre a forma de ter comportamento stateful, é importante entender que a web é stateless. Isso significa que cada requisição é tratada de forma isolada das outras. Mesmo analisando um conjunto de requisições feitas pelo mesmo cliente e em sequência, para o servidor, cada requisição é independente das outras. Essa característica faz com que servidores web de hospedagem de sites não precisem ter uma memória RAM enorme, porque ele não "se lembra" do cliente de uma requisição pra outra. Para os casos em que é necessário um comportamento stateful, a forma mais "pura" de conseguir é usando cookies. Na primeira requisição, o servidor pode gerar um ID para um cliente e armazenar em um banco de dados próprio. Então o servidor envia esse ID em um cookie e, na próxima requisição, o navegador enviará esse ID automaticamente. Cookies são usados para armazenar tokens de autenticação, para identificação de usuários anônimos e para qualquer outro uso que emule um funcionamento stateful. Por causa do abuso do compartilhamento de cookies para rastreamento de acessos de usuários, Google e Mozilla estão coordenando um esforço para restringir esse compartilhamento e melhorar a privacidade na web: https://hacks.mozilla.org/2020/08/changes-to-samesite-cookie-behavior/

Uma ótima fonte de conhecimento para temas como cache-control e cookies a MDN. Muitas dessas informações podem ser encontradas em respostas do Stack Overflow, mas não necessariamente essas respostas estarão atualizadas, então eu recomendo sempre procurar uma documentação oficial:
https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Headers/Cache-Control
https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Headers/Set-Cookie