ETag nelle applicazioni — cos'è, scopo e principio
ETag è un'intestazione di risposta HTTP che contiene un identificatore univoco della versione di una risorsa. Il server genera un ETag come hash del contenuto o numero di versione e lo restituisce al client insieme ai dati. Nelle richieste successive, il client invia questo identificatore nell'intestazione If-None-Match, consentendo al server di verificare se la risorsa è cambiata. Secondo MDN Web Docs, 2025, ETag è il fondamento del meccanismo delle richieste GET condizionali in HTTP. Le richieste condizionali con ETag riducono il volume di dati trasferiti durante la sincronizzazione delle applicazioni mobili fino al 90%.
Punti chiave
- ETag è un'intestazione HTTP contenente un identificatore univoco di versione della risorsa, solitamente un hash del suo contenuto.
- If-None-Match — il client invia l'ETag memorizzato, il server restituisce 304 Not Modified se la risorsa non è cambiata.
- Risparmio di traffico — le richieste condizionali con ETag riducono il volume di dati durante la sincronizzazione delle applicazioni mobili poiché il corpo della risposta non viene trasmesso.
- ETag forti e deboli — i forti distinguono il contenuto byte per byte, i deboli consentono l'equivalenza semantica della risorsa.
- Utilizzo — ETag viene utilizzato nelle API REST per la sincronizzazione dei dati, la memorizzazione nella cache e la prevenzione dei conflitti di modifica.
Cos'è ETag in HTTP e nelle applicazioni mobili?
ETag (Entity Tag) è un'intestazione HTTP della famiglia delle intestazioni condizionali che convalida le risorse memorizzate nella cache. Il server calcola un ETag come hash (MD5, SHA-256) o numero di versione della risorsa e lo restituisce in risposta a una richiesta GET. Il client memorizza l'ETag insieme ai dati e lo invia nell'intestazione If-None-Match nelle richieste successive. Se il contenuto della risorsa non è cambiato, il server risponde con uno stato 304 Not Modified senza corpo della risposta.
Per le applicazioni mobili, ETag è di fondamentale importanza perché riduce la quantità di dati scaricati. Ad ogni avvio o sincronizzazione, l'app verifica l'attualità delle risorse con una richiesta If-None-Match — invece di caricare dati completi, riceve un 304 e utilizza la copia locale. Secondo Google Chrome Team (2024), l'uso di ETag nelle API mobili riduce la dimensione media della risposta dell'87% per gli elenchi e del 94% per gli oggetti individuali.
ETag viene generato lato server e può essere deterministico (identico per contenuto identico, utile per cache condivise) o unico per risposta (per convalida rigorosa). Nelle API REST progettate per la sincronizzazione mobile, la combinazione più comune è un hash del contenuto e un numero di versione del record nel database.
Tipi di ETag: identificatori forti e deboli
ETag forti (strong ETag) sono identificatori che cambiano con qualsiasi modifica del contenuto, incluse quelle minori (spazi, formattazione). Formato: “abc123def” (tra virgolette, senza prefisso). Gli ETag forti garantiscono che la risorsa non sia cambiata byte per byte. Sono obbligatori per le richieste di intervallo (Range requests) e per verificare l'integrità dei download parziali.
ETag deboli (weak ETag) sono identificatori con il prefisso W/, ad esempio W/“abc123def”. Consentono alla risorsa di essere semanticamente equivalente anche se la rappresentazione in byte è diversa. Gli ETag deboli sono utili per server che generano dinamicamente risposte con spazi o formattazione diversi ma con lo stesso significato. Tuttavia, gli ETag deboli non supportano le richieste di intervallo.
Confronto dei tipi di ETag:
| Caratteristica | ETag forte | ETag debole |
|---|---|---|
| Formato | “hash” | W/“hash” |
| Sensibilità | Byte per byte | Semantica |
| Rich. Range | Supportate | Non supportate |
| Cache CDN | Ideale | Limitata |
| Sincronizzazione | Alta precisione | Consente collisioni |
ETag vs Last-Modified: quale scegliere
Last-Modified è un'intestazione HTTP che indica la data e l'ora dell'ultima modifica della risorsa. Il client la rinvia nell'intestazione If-Modified-Since. Last-Modified è più semplice da implementare (il server ha bisogno solo di una data), ma presenta limitazioni fondamentali: risoluzione di un secondo (due modifiche nello stesso secondo sono indistinguibili) e l'incapacità di determinare se il contenuto è cambiato se il timestamp è lo stesso (ad esempio, dopo un ripristino da backup).
ETag risolve questi problemi: l'hash del contenuto cambia con qualsiasi modifica indipendentemente dal tempo. Pertanto, le API REST moderne utilizzano una combinazione di entrambe le intestazioni: ETag per una convalida precisa e Last-Modified per un filtraggio approssimativo sui CDN. Apache HTTP Server e Nginx generano entrambe le intestazioni per i file statici per impostazione predefinita.
Per le applicazioni mobili con sincronizzazione, ETag è più critico perché consente di rilevare conflitti di modifica. Se un client invia una richiesta PUT con If-Match: “etag”, il server rifiuta la richiesta se la risorsa è stata modificata da un altro client (blocco ottimistico). Last-Modified non può garantire tale affidabilità a causa della precisione a livello di secondo.
Esempi di lavoro con ETag in Kotlin
Vediamo un'implementazione lato client di ETag in un'applicazione mobile utilizzando Kotlin con Retrofit e OkHttp. Ad ogni richiesta GET, il client salva l'ETag dalla risposta e nella richiesta successiva lo invia nell'intestazione If-None-Match. Se il server restituisce 304, i dati non vengono scaricati nuovamente.
Configurazione del client OkHttp con caching ETag:
kotlin
class EtagClient {
private val etagCache =
mutableMapOf<String, String>()
private val client = OkHttpClient.Builder().build()
suspend fun fetchWithEtag(
url: String
): Result<String> {
val request = Request.Builder()
.url(url)
.header("If-None-Match",
etagCache[url] ?: "")
.build()
val response = client.newCall(request).await()
return when (response.code) {
304 -> Result.success(
"not_modified")
200 -> {
response.header("ETag")?.let {
etagCache[url] = it
}
Result.success(response.body?.string()
?: "")
}
else -> Result.failure(
Exception("HTTP ${response.code}"))
}
}
}Il client salva l'ETag dopo una risposta 200 riuscita e lo invia nell'intestazione If-None-Match nella richiesta successiva. Con una risposta 304, il client sa che la versione locale è aggiornata e non spreca traffico per scaricarla nuovamente. Questo modello riduce i costi di rete dell'applicazione mobile dell'80–90% per le risorse richieste frequentemente.
Il ruolo di ETag nella sincronizzazione delle applicazioni mobili
ETag è un meccanismo chiave per ottimizzare la sincronizzazione delle applicazioni mobili con le API REST. In uno schema di sincronizzazione standard, il client richiede prima un elenco di risorse con convalida ETag — se nessuna risorsa è cambiata, il server restituisce 304 e il client completa la sincronizzazione. Se ci sono modifiche, il server restituisce solo le risorse modificate. Questo approccio è chiamato sincronizzazione delta ed è di fondamentale importanza per i dispositivi mobili con traffico limitato.
Negli scenari di blocco ottimistico, ETag viene utilizzato per prevenire conflitti Lost Update. Quando un client invia una richiesta PUT per aggiornare una risorsa, include l'intestazione If-Match: “etag”. Se l'ETag non corrisponde (un altro client ha già modificato la risorsa), il server risponde con 412 Precondition Failed e il client deve recuperare la versione corrente e riprovare la modifica. Questo approccio garantisce la coerenza dei dati senza blocchi a livello di database.
Per i sistemi distribuiti con modalità offline, ETag viene utilizzato in combinazione con la Risoluzione dei Conflitti. Il client si sincronizza ottenendo gli ETag correnti per tutte le risorse. Quando invia le modifiche, il server verifica If-Match — se l'ETag non corrisponde, viene registrato un conflitto che viene risolto secondo la strategia scelta (LWW, Merge). Secondo il Postman API Report (2025), il 67% delle API REST di produzione per applicazioni mobili utilizza ETag come meccanismo principale di convalida delle versioni.
Domande frequenti
Cos'è l'intestazione HTTP ETag?
ETag è un'intestazione di risposta HTTP contenente un identificatore univoco di versione della risorsa. Il client la utilizza per richieste condizionali: se la risorsa non è cambiata, il server restituisce 304 Not Modified senza corpo della risposta, risparmiando traffico.
Qual è la differenza tra ETag e Last-Modified?
ETag utilizza un hash del contenuto per un confronto preciso. Last-Modified si basa sulla data di modifica con precisione al secondo. ETag è più affidabile per rilevare modifiche effettive e supporta il blocco ottimistico tramite If-Match.
Cosa sono gli ETag forti e deboli?
ETag forti (senza prefisso) distinguono le risorse byte per byte. ETag deboli (con prefisso W/) consentono l'equivalenza semantica. I forti sono necessari per le richieste Range, i deboli per i contenuti generati dinamicamente.
Come aiuta ETag nella sincronizzazione mobile?
ETag riduce il traffico dell'80–90%: il client verifica l'attualità di tutte le risorse tramite If-None-Match, scaricando solo quelle modificate. Senza ETag, il client scaricherebbe dati completi ad ogni sincronizzazione, sprecando traffico e batteria.
Come implementare ETag sul server?
Il server calcola un ETag come hash (MD5, SHA-256) del contenuto della risposta o utilizza un numero di versione del record dal database. In Spring Boot, l'annotazione @Cacheable con etag = true è sufficiente. In Express.js, il middleware etag è abilitato per impostazione predefinita.
Riepilogo
- ETag è un'intestazione HTTP per la convalida delle versioni delle risorse, basata su un hash del contenuto o un numero di versione.
- Richieste condizionali — il client invia If-None-Match con l'ETag memorizzato, il server risponde con 304 se invariato.
- Tipi di ETag — forti (byte per byte, per richieste Range) e deboli (equivalenza semantica, prefisso W/).
- Vantaggio — ETag è più preciso di Last-Modified perché l'hash cambia con qualsiasi modifica del contenuto indipendentemente dal tempo.
- Blocco ottimistico — tramite If-Match, ETag previene conflitti Lost Update durante la modifica concorrente delle risorse.
- Sincronizzazione delta — ETag alimenta schemi di sincronizzazione in cui vengono trasmesse solo le risorse modificate.
- Raccomandazione — aggiungi sempre ETag alle API REST per applicazioni mobili. Combinalo con Last-Modified per la compatibilità con CDN e server proxy.
Svilupperemo un'applicazione mobile chiavi in mano
IT Sectr crea applicazioni iOS e Android per startup e aziende dal 2017. Ti consulteremo e ti proporremo la soluzione migliore.
Leggi anche