ETag az alkalmazásokban — mi ez, célja és elve
ETag — HTTP válaszfejléc, amely az erőforrás verziójának egyedi azonosítóját tartalmazza. A szerver ETag-ot állít elő a tartalom hash-e vagy verziószáma alapján, és az adatokkal együtt visszaküldi a kliensnek. A későbbi kéréseknél a kliens ezt az azonosítót küldi az If-None-Match fejlécben, lehetővé téve a szerver számára, hogy ellenőrizze, változott-e az erőforrás. A MDN Web Docs, 2025 szerint az ETag képezi a feltételes GET kérések mechanizmusának alapját HTTP-ben. Az ETag-gal ellátott feltételes kérések akár 90%-kal csökkentik a mobilalkalmazások szinkronizálásakor továbbított adatok mennyiségét.
Főbb pontok
- ETag — HTTP fejléc, amely az erőforrás verziójának egyedi azonosítóját tartalmazza, általában a tartalom hash-ét.
- If-None-Match — a kliens elküldi a mentett ETag-ot, a szerver 304 Not Modified-ot küld vissza, ha az erőforrás nem változott.
- Forgalom megtakarítás — a feltételes kérések ETag-gal csökkentik az adatmennyiséget a mobilalkalmazások szinkronizálásakor, mivel a válasz törzse nem kerül továbbításra.
- Erős és gyenge ETag — az erősek bájtonként különböztetik meg a tartalmat, a gyengék szemantikai egyenértékűséget engednek meg.
- Alkalmazás — az ETag REST API-ban használatos adatszinkronizáláshoz, gyorsítótárazáshoz és szerkesztési konfliktusok megelőzéséhez.
Mi az ETag HTTP-ben és mobilalkalmazásokban?
ETag (Entity Tag) — HTTP fejléc a feltételes fejlécek családjából, amely biztosítja a gyorsítótárazott erőforrások érvényesítését. A szerver az ETag-ot hash összegként (MD5, SHA-256) vagy az erőforrás verziószámaként számítja ki, és visszaadja a GET kérésre adott válaszban. A kliens az ETag-ot az adatokkal együtt tárolja, és a következő kérésnél elküldi a If-None-Match fejlécben. Ha az erőforrás tartalma nem változott, a szerver 304 Not Modified státusszal válaszol a válasz törzse nélkül.
Mobilalkalmazások számára az ETag kritikus jelentőségű, mivel csökkenti a letöltendő adatok mennyiségét. Minden indításnál vagy szinkronizálásnál az alkalmazás If-None-Match kéréssel ellenőrzi az erőforrások frissességét — a teljes adatletöltés helyett 304-et kap, és a helyi másolatot használja. A Google Chrome Team (2024) szerint az ETag használata a mobil API-kban átlagosan 87%-kal csökkenti a válasz méretét listák esetén és 94%-kal egyedi objektumok esetén.
Az ETag a szerver oldalon jön létre, és lehet determinisztikus (azonos azonos tartalom esetén, ami a megosztott gyorsítótáraknál hasznos) és egyedi minden válaszhoz (szigorú érvényesítéshez). A mobil szinkronizálásra tervezett REST API-kban leggyakrabban a tartalom hash-ének és az adatbázisrekord verziószámának kombinációját használják.
ETag típusok: erős és gyenge azonosítók
Erős ETag (strong ETag) — azonosítók, amelyek a tartalom bármilyen változásánál megváltoznak, beleértve a kisebbeket is (szóközök, formázás). Formátum: "abc123def" (idézőjelek között, előtag nélkül). Az erős ETag-ok garantálják, hogy az erőforrás bájtonként nem változott. Kötelezőek a tartománykérésekhez (Range requests) és a részleges letöltések integritásának ellenőrzéséhez.
Gyenge ETag (weak ETag) — W/ előtaggal ellátott azonosítók, például W/"abc123def". Lehetővé teszik, hogy az erőforrás szemantikailag egyenértékű legyen, még ha a bájtos reprezentáció eltér is. A gyenge ETag-ok hasznosak azon szerverek számára, amelyek dinamikusan, eltérő szóközökkel vagy formázással, de azonos jelentéssel állítanak elő válaszokat. A gyenge ETag-ok azonban nem támogatják a tartománykéréseket.
Az ETag típusok összehasonlítása:
| Jellemző | Erős ETag | Gyenge ETag |
|---|---|---|
| Formátum | "hash" | W/"hash" |
| Érzékenység | Bájtonként | Szemantikai |
| Tartománykérések | Támogatott | Nem támogatott |
| CDN gyorsítótárazás | Ideális | Korlátozott |
| Szinkronizálás | Magas pontosság | Ütközéseket enged |
ETag kontra Last-Modified: mit válasszunk
Last-Modified — HTTP fejléc, amely az erőforrás utolsó módosításának dátumát és idejét jelzi. A kliens ezt küldi vissza az If-Modified-Since fejlécben. A Last-Modified egyszerűbben implementálható (a szervernek csak dátumra van szüksége), de alapvető korlátai vannak: egy másodperces felbontás (egy másodpercen belüli két változás megkülönböztethetetlen) és képtelenség annak meghatározására, hogy a tartalom változott-e azonos időpontban (pl. biztonsági másolatból történő visszaállítás után).
Az ETag megoldja ezeket a problémákat: a tartalom hash-e minden változásnál módosul, időtől függetlenül. Emiatt a modern REST API-k mindkét fejléc kombinációját használják: ETag a pontos érvényesítéshez és Last-Modified a közelítő szűréshez CDN-ben. Az Apache HTTP Server és az Nginx alapértelmezetten mindkét fejlécet generálja statikus fájlokhoz.
A szinkronizálással rendelkező mobilalkalmazások számára az ETag kritikusabb, mivel lehetővé teszi a szerkesztési konfliktusok észlelését. Ha a kliens PUT kérést küld az If-Match: "etag" fejléccel, a szerver elutasítja a kérést, ha az erőforrást egy másik kliens módosította (optimista zárolás). A Last-Modified a másodperces pontosság miatt nem tud ilyen megbízhatóságot garantálni.
Példák ETag használatra Kotlinban
Nézzük meg a kliens oldali implementációt ETag-hoz egy mobilalkalmazásban Kotlin nyelven, Retrofit és OkHttp használatával. Minden GET kérésnél a kliens elmenti az ETag-ot a válaszból, a következő kérésnél pedig elküldi az If-None-Match fejlécben. Ha a szerver 304-et küld vissza, az adatok nem töltődnek le újra.
Az OkHttp kliens konfigurálása ETag gyorsítótárazással:
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}"))
}
}
}A kliens sikeres 200-as válasz után elmenti az ETag-ot, és a következő kérésnél elküldi a If-None-Match fejlécben. 304-es válasznál a kliens tudja, hogy a helyi verzió naprakész, és nem pazarolja a forgalmat az adatok újratöltésére. Ez a minta 80–90%-kal csökkenti a mobilalkalmazás hálózati költségeit a gyakran kért erőforrások esetén.
Az ETag szerepe a mobilalkalmazások szinkronizálásában
Az ETag kulcsfontosságú mechanizmus a mobilalkalmazások REST API-val történő szinkronizálásának optimalizálásához. A standard szinkronizálási sémában a kliens először ETag érvényesítéssel kéri az erőforrások listáját — ha egyetlen erőforrás sem változott, a szerver 304-et küld, és a kliens befejezi a szinkronizálást. Ha vannak változások, a szerver csak a módosított erőforrásokat küldi vissza. Ezt a megközelítést delta-szinkronizálásnak nevezik, és kritikus a korlátozott forgalmú mobileszközök számára.
Optimista zárolás esetén az ETag a Lost Update konfliktusok megelőzésére szolgál. Amikor a kliens PUT kérést küld az erőforrás frissítésére, belefoglalja az If-Match: "etag" fejlécet. Ha az ETag nem egyezik (egy másik kliens már módosította az erőforrást), a szerver 412 Precondition Failed választ küld, és a kliensnek újra le kell töltenie az aktuális verziót, majd megismételnie a módosítást. Ez a megközelítés biztosítja az adatok konzisztenciáját adatbázis szintű zárolások nélkül.
Elosztott rendszerekben offline módban az ETag konfliktusmegoldással kombinálva használatos. A kliens az összes erőforráshoz aktuális ETag-okat kérve szinkronizál. A módosítások elküldésekor a szerver ellenőrzi az If-Match-ot — ha az ETag nem egyezik, a választott stratégia (LWW, Merge) szerint feloldandó konfliktus kerül rögzítésre. A Postman API Report (2025) szerint a mobilalkalmazásokhoz készült production REST API-k 67%-a használja az ETag-ot elsődleges verzió-érvényesítési mechanizmusként.
Gyakran Ismételt Kérdések
Mi az HTTP ETag fejléc?
ETag — HTTP válaszfejléc, amely az erőforrás verziójának egyedi azonosítóját tartalmazza. A kliens feltételes kérésekhez használja: ha az erőforrás nem változott, a szerver 304 Not Modified választ küld a válasz törzse nélkül, forgalmat megtakarítva.
Mi a különbség az ETag és a Last-Modified között?
ETag a tartalom hash-ét használja pontos összehasonlításhoz. Last-Modified a módosítás dátumán alapul egy másodperces pontossággal. Az ETag megbízhatóbb a valós változások észlelésében, és támogatja az optimista zárolást az If-Match-en keresztül.
Mik az erős és gyenge ETag-ok?
Erős ETag-ok (előtag nélkül) bájtonként különböztetik meg az erőforrásokat. Gyenge ETag-ok (W/ előtaggal) szemantikai egyenértékűséget engednek meg. Az erősek tartománykérésekhez szükségesek, a gyengék dinamikusan generált tartalomhoz.
Hogyan segít az ETag a mobil szinkronizálásban?
Az ETag 80–90%-kal csökkenti a forgalmat: a kliens az If-None-Match-en keresztül ellenőrzi az összes erőforrás frissességét, csak a megváltozottakat tölti le. ETag nélkül a kliens minden szinkronizáláskor teljes adatokat töltene le, forgalmat és akkumulátort pazarolva.
Hogyan implementálható az ETag a szerveren?
A szerver az ETag-ot a válasz tartalmának hash-eként (MD5, SHA-256) számítja ki, vagy az adatbázisrekord verziószámát használja. Spring Boot-ban a @Cacheable annotáció etag = true paraméterrel elegendő. Express.js-ben az etag middleware alapértelmezetten be van kapcsolva.
Összegzés
- ETag — HTTP fejléc erőforrás-verziók érvényesítéséhez, a tartalom hash-én vagy verziószámán alapulva.
- Feltételes kérések — a kliens If-None-Match-ot küld a mentett ETag-gal, a szerver 304-gyel válaszol változás hiányában.
- ETag típusok — erős (bájtonként, tartománykérésekhez) és gyenge (szemantikai egyenértékűség, W/ előtag).
- Előny — az ETag pontosabb, mint a Last-Modified, mert a hash a tartalom minden változásánál módosul, időtől függetlenül.
- Optimista zárolás — az If-Match-en keresztül az ETag megakadályozza a Lost Update konfliktusokat párhuzamos erőforrás-szerkesztésnél.
- Delta-szinkronizálás — ETag-alapú szinkronizálási sémák, ahol csak a módosított erőforrások kerülnek továbbításra.
- Javaslat — mindig adjon hozzá ETag-ot a REST API-hoz mobilalkalmazásokhoz. Kombinálja Last-Modified-del a CDN-ekkel és proxy szerverekkel való kompatibilitás érdekében.
Kulcsrakész mobilalkalmazást fejlesztünk
Az IT Sectr 2017 óta készít iOS és Android alkalmazásokat induló vállalkozásoknak és vállalkozásoknak. Tanácsot adunk, és a legjobb megoldást javasoljuk.
Olvassa el is