ETag în aplicații — ce este, scopul și principiul
ETag — un antet de răspuns HTTP care conține un identificator unic al versiunii resursei. Serverul generează ETag ca hash al conținutului sau număr de versiune și îl returnează clientului împreună cu datele. La solicitările ulterioare, clientul trimite acest identificator în antetul If-None-Match, permițând serverului să verifice dacă resursa s-a modificat. Conform MDN Web Docs, 2025, ETag stă la baza mecanismului solicitărilor GET condiționate în HTTP. Solicitările condiționate cu ETag reduc volumul de date transmise la sincronizarea aplicațiilor mobile cu până la 90%.
Principalele
- ETag — antet HTTP care conține un identificator unic al versiunii resursei, de obicei hash-ul conținutului său.
- If-None-Match — clientul trimite ETag-ul salvat, serverul returnează 304 Not Modified dacă resursa nu s-a modificat.
- Economie de trafic — solicitările condiționate cu ETag reduc volumul de date la sincronizarea aplicațiilor mobile, deoarece corpul răspunsului nu este transmis.
- ETag puternice și slabe — cele puternice diferențiază conținutul byte cu byte, cele slabe admit echivalența semantică a resursei.
- Aplicare — ETag este utilizat în REST API pentru sincronizarea datelor, cache și prevenirea conflictelor de editare.
Ce este ETag în HTTP și aplicațiile mobile?
ETag (Entity Tag) — antet HTTP din familia antetelor condiționate care asigură validarea resurselor stocate în cache. Serverul calculează ETag ca sumă hash (MD5, SHA-256) sau număr de versiune al resursei și îl returnează în răspunsul la solicitarea GET. Clientul salvează ETag împreună cu datele și la solicitarea următoare îl trimite în antetul If-None-Match. Dacă conținutul resursei nu s-a modificat, serverul răspunde cu statusul 304 Not Modified fără corpul răspunsului.
Pentru aplicațiile mobile, ETag este critic deoarece reduce volumul datelor descărcate. La fiecare lansare sau sincronizare, aplicația verifică actualitatea resurselor printr-o solicitare cu If-None-Match — în loc să descarce datele complete, primește 304 și folosește copia locală. Conform Google Chrome Team (2024), utilizarea ETag în API-urile mobile reduce volumul mediu al răspunsului cu 87% pentru liste și cu 94% pentru obiecte individuale.
ETag este generat pe partea serverului și poate fi atât determinist (identic pentru același conținut, util pentru cache-urile partajate), cât și unic pentru fiecare răspuns (pentru validare strictă). În REST API-urile destinate sincronizării mobile, cel mai des se utilizează o combinație între hash-ul conținutului și numărul versiunii înregistrării în baza de date.
Tipuri de ETag: identificatori puternici și slabi
ETag puternic (strong ETag) — identificatori care se modifică la orice schimbare a conținutului, inclusiv cele minore (spații, formatare). Format: "abc123def" (în ghilimele, fără prefix). ETag-urile puternice garantează că resursa nu s-a modificat byte cu byte. Acestea sunt obligatorii pentru solicitările de interval (Range requests) și pentru verificarea integrității descărcărilor parțiale.
ETag slab (weak ETag) — identificatori cu prefixul W/, de exemplu W/"abc123def". Aceștia admit că resursa este echivalentă semantic, chiar dacă reprezentarea în bytes diferă. ETag-urile slabe sunt utile pentru serverele care generează dinamic răspunsuri cu spații sau formatări diferite, dar cu același sens. Cu toate acestea, ETag-urile slabe nu suportă solicitările de interval.
Compararea tipurilor de ETag:
| Caracteristică | ETag puternic | ETag slab |
|---|---|---|
| Format | "hash" | W/"hash" |
| Sensibilitate | Byte cu byte | Semantică |
| Solicitări de interval | Suportate | Nu sunt suportate |
| Cache CDN | Ideal | Limitat |
| Sincronizare | Precizie ridicată | Admite coliziuni |
ETag versus Last-Modified: ce să alegem
Last-Modified — antet HTTP care indică data și ora ultimei modificări a resursei. Clientul îl trimite înapoi în antetul If-Modified-Since. Last-Modified este mai simplu de implementat (serverul are nevoie doar de dată), dar are limitări fundamentale: rezoluția de o secundă (două modificări într-o secundă sunt indistinguibile) și imposibilitatea de a determina dacă conținutul s-a modificat la aceeași oră (de exemplu, după restaurarea din backup).
ETag rezolvă aceste probleme: hash-ul conținutului se modifică la orice schimbare independent de timp. De aceea, REST API-urile moderne utilizează o combinație a ambelor antete: ETag pentru validare precisă și Last-Modified pentru filtrarea aproximativă în CDN. Apache HTTP Server și Nginx generează implicit ambele antete pentru fișierele statice.
Pentru aplicațiile mobile cu sincronizare, ETag este mai critic deoarece permite detectarea conflictelor de editare. Dacă clientul trimite un PUT cu antetul If-Match: "etag", serverul respinge solicitarea dacă resursa a fost modificată de un alt client (blocare optimistă). Last-Modified nu poate garanta o astfel de fiabilitate din cauza preciziei de o secundă.
Exemple de lucru cu ETag în Kotlin
Să examinăm implementarea clientă a ETag într-o aplicație mobilă în Kotlin folosind Retrofit și OkHttp. La fiecare solicitare GET, clientul salvează ETag-ul din răspuns, iar la următoarea solicitare îl trimite în antetul If-None-Match. Dacă serverul returnează 304, datele nu sunt descărcate din nou.
Configurarea clientului OkHttp cu cache 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}"))
}
}
}Clientul salvează ETag după un răspuns reușit 200 și îl trimite în antetul If-None-Match la următoarea solicitare. La 304, clientul știe că versiunea locală este actualizată și nu consumă trafic pentru re-descărcarea datelor. Acest model reduce costurile de rețea ale aplicației mobile cu 80–90% pentru resursele frecvent solicitate.
Rolul ETag în sincronizarea aplicațiilor mobile
ETag este un mecanism cheie pentru optimizarea sincronizării aplicațiilor mobile cu REST API. În schema standard de sincronizare, clientul solicită mai întâi lista resurselor cu validare ETag — dacă nicio resursă nu s-a modificat, serverul returnează 304 și clientul încheie sincronizarea. Dacă există modificări, serverul returnează doar resursele modificate. Această abordare se numește sincronizare delta și este critică pentru dispozitivele mobile cu trafic limitat.
În scenariile cu blocare optimistă, ETag este utilizat pentru prevenirea conflictelor Lost Update. Când clientul trimite un PUT pentru actualizarea resursei, include antetul If-Match: "etag". Dacă ETag nu se potrivește (un alt client a modificat deja resursa), serverul răspunde cu 412 Precondition Failed, iar clientul trebuie să re-descarce versiunea actualizată și să reia modificarea. Această abordare asigură coerența datelor fără blocaje la nivelul bazei de date.
Pentru sistemele distribuite cu mod offline, ETag este utilizat în combinație cu Rezolvarea Conflictelor. Clientul se sincronizează obținând ETag-urile curente pentru toate resursele. La trimiterea modificărilor, serverul verifică If-Match — dacă ETag nu se potrivește, se înregistrează un conflict care se rezolvă conform strategiei alese (LWW, Merge). Conform Postman API Report (2025), 67% din REST API-urile de producție pentru aplicații mobile utilizează ETag ca mecanism principal de validare a versiunilor.
Întrebări frecvente
Ce este antetul HTTP ETag?
ETag — antet de răspuns HTTP care conține un identificator unic al versiunii resursei. Clientul îl folosește pentru solicitări condiționate: dacă resursa nu s-a modificat, serverul returnează 304 Not Modified fără corpul răspunsului, economisind trafic.
Care este diferența dintre ETag și Last-Modified?
ETag folosește hash-ul conținutului pentru comparare precisă. Last-Modified se bazează pe data modificării cu precizie de o secundă. ETag este mai fiabil pentru detectarea modificărilor reale și suportă blocarea optimistă prin If-Match.
Ce sunt ETag-urile puternice și slabe?
ETag-urile puternice (fără prefix) diferențiază resursele byte cu byte. ETag-urile slabe (cu prefixul W/) admit echivalența semantică. Cele puternice sunt necesare pentru solicitările de interval, cele slabe — pentru conținut generat dinamic.
Cum ajută ETag la sincronizarea mobilă?
ETag reduce traficul cu 80–90%: clientul verifică actualitatea tuturor resurselor prin If-None-Match, descărcând doar resursele modificate. Fără ETag, clientul ar descărca datele complete la fiecare sincronizare, consumând trafic și baterie.
Cum se implementează ETag pe server?
Serverul calculează ETag ca hash (MD5, SHA-256) al conținutului răspunsului sau folosește numărul versiunii înregistrării din baza de date. În Spring Boot, adnotarea @Cacheable cu etag = true este suficientă. În Express.js, middleware-ul etag este activat implicit.
Rezumat
- ETag — antet HTTP pentru validarea versiunilor resurselor, bazat pe hash-ul conținutului sau numărul versiunii.
- Solicitări condiționate — clientul trimite If-None-Match cu ETag-ul salvat, serverul răspunde 304 la absența modificărilor.
- Tipuri de ETag — puternice (byte cu byte, pentru solicitări de interval) și slabe (echivalență semantică, prefix W/).
- Avantaj — ETag este mai precis decât Last-Modified, deoarece hash-ul se modifică la orice schimbare a conținutului independent de timp.
- Blocare optimistă — prin If-Match, ETag previne conflictele Lost Update la editarea concurentă a resurselor.
- Sincronizare delta — pe ETag se bazează schemele de sincronizare în care se transmit doar resursele modificate.
- Recomandare — adăugați întotdeauna ETag în REST API pentru aplicațiile mobile. Combinați cu Last-Modified pentru compatibilitate cu CDN-uri și servere proxy.
Vom dezvolta o aplicație mobilă la cheie
IT Sectr creează aplicații iOS și Android pentru startup-uri și afaceri din 2017. Vă vom consilia și vă vom propune cea mai bună soluție.
Citiți și