Duas preocupações que existem ao desenvolver uma API com boa performance são tempo de resposta e trafegar “pouca” informação. Uma das soluções para essa situação é o uso do cache e nesse post vou abordar a técnica usando ETag.

ETag, abreviação de “entity tag”, é um mecanismo de cache a nível do protocolo HTTP. O uso de ETags é padrão no Rails desde sua versão 3.0 e seu valor, que é determinado por um digest do conteúdo gerado no servidor, é enviado no cabeçalho das requisições HTTP. Sempre que um conteúdo relevante é alterado na resposta do servidor, a ETag também muda e expira. Desta forma, o servidor define se o cliente pode usar o conteúdo previamente armazenado na última requisição (HTTP status-code: 304) ou se o servidor precisa enviar uma nova resposta (HTTP status-code: 200).

Ao chamar a API pela primeira vez, não temos nenhum valor de ETag armazenado no cliente.

$curl -I http://localhost:3000/articles/1.json
HTTP/1.1 200 OK
Etag: "0835b0c055a88af2d0ef4f6890cee95d"

Agora, se fizer uma nova requisição com essa ETag, a resposta é diferente:

$ curl -H 'If-None-Match: "0835b0c055a88af2d0ef4f6890cee95d"' -I http://localhost:3000/articles/1.json
HTTP/1.1 304 Not Modified
Etag: "0835b0c055a88af2d0ef4f6890cee95d"

O HTTP status-code é 304 e isto quer dizer que o conteúdo não foi modificado. Essa “economia” só existe se o ETag for enviado no cabeçalho da requisição. E então, esse comportamento deve ser tratado pelo cliente. Como a resposta é “não modificado”, o corpo dessa requisição vem completamente em branco.

Continue lendo em: https://helabs.com/artigos/2014/04/04/cache-de-api-usando-etag/