> For the complete documentation index, see [llms.txt](https://consumindo-apis-com-elixir.cafecomelixir.com.br/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://consumindo-apis-com-elixir.cafecomelixir.com.br/compondo-integracoes/aproveitando-ao-maximo-o-rate-limit.md).

# Aproveitando ao máximo o Rate Limit

Mesmo tendo mecanismos para lidar com o *Rate Limit* ultrapassado, precisamos também aproveitar ao máximo as requisições e tentar não entrar na penalidade, ou entrar o mínimo possível, para entregar uma experiência melhor ao usuário.

Uma das formas de fazer isso é utilizando *ETag*, um mecanismo de versionamento de recurso.

Hoje nossa aplicação funciona assim

<figure><img src="https://662465308-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FegTKEnXxNB5i4htSH2x4%2Fuploads%2Fn9Jo0XpRlMg9CGxn32d8%2Fimage.png?alt=media&amp;token=15ddf9bc-76a6-416f-8803-4904623ee907" alt=""><figcaption></figcaption></figure>

Vamos recapitular.

Nossa aplicação realiza uma requisição para o serviço externo requisitando o recurso `/coffee/hot`. O serviço externo processa, pega os dados de algum sistema de armazenamento e retorna o recurço. Na resposta recebemos um cabeçalho com  `x-ratelimit-remaining` . Toda vez que fizermos esse processo, esse cabeçalho diminuirá 1, até chegar a zero e então receberemos o erro de status 429 acusando que fizemos requisições demais em um curto período de tempo.

Imagine agora que o serviço externo versiona os dados do recurso. Isso quer dizer, toda vez que o dado muda, ou um cafezinho é adicionado, ele gera um código informando que essa é a versão atual e responde esse código pelo cabeçalho para nós, quem está requisitando o recurso. Vamos dizer que o código seja 123456. Chegou a hora que precisamos fazer novamente um requisição a esse recurso, pois alguém chamou a função de integração. Tendo o código da versão do recurso podemos mandar por cabeçalho. Feito isso, do o serviço analisara esse código, verificando se é a versão atual. Se não foi, ele irá retornar os dados do recurso, junto com o codigo mais recente. Caso o código que nós enviamos seja igual ao da versão atual, ele vai nos responder com status `304 Not Modified` e o corpo da requisição virá vazia. Isso quer dizer que o dado que temos é o atualizado.

<figure><img src="https://662465308-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FegTKEnXxNB5i4htSH2x4%2Fuploads%2F7hznxntrDldfBh2Vgaoo%2Fimage.png?alt=media&amp;token=b78f80b6-fee4-43a9-bcb0-38e2181cfeca" alt=""><figcaption></figcaption></figure>

Nesse cenário o `x-ratelimit-remaining` não é decrementado. Isso acontece devido a não ter processado o dado no lado do serviço. Essa regra faz com que não consumemos muito recurso, com isso não nos penalizando.

Porém, não recebemos o dado na requisição. Precisamos ter ele em nossa aplicação em alguma forma de armazenamento. No nossa caso, podemos adicionar no banco de dados.