ETag v aplikacích — co to je, účel a princip
ETag — HTTP hlavička odpovědi obsahující unikátní identifikátor verze zdroje. Server generuje ETag jako hash obsahu nebo číslo verze a vrací jej klientovi spolu s daty. Při následujících požadavcích klient odesílá tento identifikátor v hlavičce If-None-Match, což serveru umožňuje zkontrolovat, zda se zdroj změnil. Podle MDN Web Docs, 2025 je ETag základem mechanismu podmíněných GET požadavků v HTTP. Podmíněné požadavky s ETag snižují objem přenášených dat při synchronizaci mobilních aplikací až o 90%.
Hlavní body
- ETag — HTTP hlavička obsahující unikátní identifikátor verze zdroje, obvykle hash jeho obsahu.
- If-None-Match — klient odesílá uložený ETag, server vrací 304 Not Modified, pokud se zdroj nezměnil.
- Úspora provozu — podmíněné požadavky s ETag snižují objem dat při synchronizaci mobilních aplikací, protože tělo odpovědi se nepřenáší.
- Silné a slabé ETag — silné rozlišují obsah bajt po bajtu, slabé připouštějí sémantickou ekvivalenci zdroje.
- Použití — ETag se používá v REST API pro synchronizaci dat, cachování a prevenci konfliktů při editaci.
Co je ETag v HTTP a mobilních aplikacích?
ETag (Entity Tag) — HTTP hlavička z rodiny podmíněných hlaviček, která zajišťuje validaci cachovaných zdrojů. Server vypočítá ETag jako hash sumu (MD5, SHA-256) nebo číslo verze zdroje a vrátí jej v odpovědi na GET požadavek. Klient uloží ETag spolu s daty a při opakovaném požadavku jej odešle v hlavičce If-None-Match. Pokud se obsah zdroje nezměnil, server odpoví stavem 304 Not Modified bez těla odpovědi.
Pro mobilní aplikace je ETag kritický, protože snižuje objem stahovaných dat. Při každém spuštění nebo synchronizaci aplikace kontroluje aktuálnost zdrojů požadavkem s If-None-Match — místo plného stažení dat obdrží 304 a použije lokální kopii. Podle Google Chrome Team (2024) použití ETag v mobilních API snižuje průměrný objem odpovědi o 87% pro seznamy a o 94% pro jednotlivé objekty.
ETag se generuje na straně serveru a může být jak deterministický (stejný pro stejný obsah, užitečný pro sdílené cache), tak unikátní pro každou odpověď (pro přísnou validaci). V REST API určených pro mobilní synchronizaci se nejčastěji používá kombinace hashe obsahu a čísla verze záznamu v databázi.
Typy ETag: silné a slabé identifikátory
Silný ETag (strong ETag) — identifikátory, které se mění při každé změně obsahu, včetně nepatrných (mezery, formátování). Formát: "abc123def" (v uvozovkách, bez prefixu). Silné ETag zaručují, že se zdroj nezměnil bajt po bajtu. Jsou povinné pro požadavky na rozsah (Range requests) a pro kontrolu integrity částečných stažení.
Slabý ETag (weak ETag) — identifikátory s prefixem W/, například W/"abc123def". Připouštějí, že zdroj je sémanticky ekvivalentní, i když se bajtová reprezentace liší. Slabé ETag jsou užitečné pro servery, které dynamicky generují odpovědi s různými mezerami nebo formátováním, ale stejným významem. Slabé ETag však nepodporují požadavky na rozsah.
Srovnání typů ETag:
| Vlastnost | Silný ETag | Slabý ETag |
|---|---|---|
| Formát | "hash" | W/"hash" |
| Citlivost | Bajt po bajtu | Sémantická |
| Požadavky na rozsah | Podporovány | Nejsou podporovány |
| Cachování CDN | Ideální | Omezené |
| Synchronizace | Vysoká přesnost | Připouští kolize |
ETag versus Last-Modified: co vybrat
Last-Modified — HTTP hlavička udávající datum a čas poslední změny zdroje. Klient ji odesílá zpět v hlavičce If-Modified-Since. Last-Modified je jednodušší na implementaci (server potřebuje pouze datum), ale má zásadní omezení: rozlišení jedné sekundy (dvě změny v jedné sekundě jsou nerozlišitelné) a nemožnost určit, zda se obsah změnil ve stejném čase (např. po obnovení ze zálohy).
ETag tyto problémy řeší: hash obsahu se mění při každé změně nezávisle na čase. Moderní REST API proto používají kombinaci obou hlaviček: ETag pro přesnou validaci a Last-Modified pro přibližné filtrování na CDN. Apache HTTP Server a Nginx ve výchozím nastavení generují obě hlavičky pro statické soubory.
Pro mobilní aplikace se synchronizací je ETag kritičtější, protože umožňuje detekovat konflikty při editaci. Pokud klient odešle PUT požadavek s hlavičkou If-Match: "etag", server požadavek zamítne, pokud byl zdroj změněn jiným klientem (optimistické zamykání). Last-Modified kvůli sekundové přesnosti nemůže takovou spolehlivost zaručit.
Příklady práce s ETag v Kotlin
Podívejme se na klientskou implementaci ETag v mobilní aplikaci v Kotlin pomocí Retrofit a OkHttp. Při každém GET požadavku klient uloží ETag z odpovědi a při dalším požadavku jej odešle v hlavičce If-None-Match. Pokud server vrátí 304, data se nestahují znovu.
Konfigurace OkHttp klienta s cachováním 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}"))
}
}
}Klient uloží ETag po úspěšné odpovědi 200 a odešle jej v hlavičce If-None-Match při dalším požadavku. Při 304 klient ví, že lokální verze je aktuální, a neplýtvá provozem na opakované stahování dat. Tento vzor snižuje síťové náklady mobilní aplikace o 80–90% u často požadovaných zdrojů.
Role ETag v synchronizaci mobilních aplikací
ETag je klíčový mechanismus pro optimalizaci synchronizace mobilních aplikací s REST API. Při standardním schématu synchronizace klient nejprve požaduje seznam zdrojů s ETag validací — pokud se žádný zdroj nezměnil, server vrátí 304 a klient synchronizaci ukončí. Pokud došlo ke změnám, server vrátí pouze změněné zdroje. Tento přístup se nazývá delta synchronizace a je kritický pro mobilní zařízení s omezeným provozem.
V scénářích s optimistickým zamykáním se ETag používá k prevenci konfliktů Lost Update. Když klient odešle PUT požadavek na aktualizaci zdroje, zahrne hlavičku If-Match: "etag". Pokud ETag nesouhlasí (jiný klient již zdroj změnil), server odpoví 412 Precondition Failed a klient musí znovu stáhnout aktuální verzi a změnu zopakovat. Tento přístup zajišťuje konzistenci dat bez zamykání na úrovni databáze.
Pro distribuované systémy s offline režimem se ETag používá v kombinaci s řešením konfliktů. Klient synchronizuje získáním aktuálních ETag pro všechny zdroje. Při odesílání změn server zkontroluje If-Match — pokud ETag nesouhlasí, zaznamená se konflikt, který se řeší podle zvolené strategie (LWW, Merge). Podle Postman API Report (2025) 67% produkčních REST API pro mobilní aplikace používá ETag jako hlavní mechanismus validace verzí.
Často kladené otázky
Co je HTTP hlavička ETag?
ETag — HTTP hlavička odpovědi obsahující unikátní identifikátor verze zdroje. Klient ji používá pro podmíněné požadavky: pokud se zdroj nezměnil, server vrátí 304 Not Modified bez těla odpovědi, čímž šetří provoz.
Jaký je rozdíl mezi ETag a Last-Modified?
ETag používá hash obsahu pro přesné porovnání. Last-Modified je založen na datu změny s přesností na sekundu. ETag je spolehlivější pro detekci skutečných změn a podporuje optimistické zamykání přes If-Match.
Co jsou silné a slabé ETag?
Silné ETag (bez prefixu) rozlišují zdroje bajt po bajtu. Slabé ETag (s prefixem W/) připouštějí sémantickou ekvivalenci. Silné jsou vyžadovány pro požadavky na rozsah, slabé pro dynamicky generovaný obsah.
Jak ETag pomáhá při mobilní synchronizaci?
ETag snižuje provoz o 80–90%: klient kontroluje aktuálnost všech zdrojů přes If-None-Match, stahuje pouze změněné. Bez ETag by klient při každé synchronizaci stahoval plná data, čímž by plýtval provozem a baterií.
Jak implementovat ETag na serveru?
Server vypočítá ETag jako hash (MD5, SHA-256) obsahu odpovědi nebo použije číslo verze záznamu z databáze. V Spring Boot stačí anotace @Cacheable s etag = true. V Express.js je middleware etag ve výchozím nastavení zapnutý.
Shrnutí
- ETag — HTTP hlavička pro validaci verzí zdrojů, založená na hashi obsahu nebo čísle verze.
- Podmíněné požadavky — klient odesílá If-None-Match s uloženým ETag, server odpovídá 304 při neexistenci změn.
- Typy ETag — silné (bajt po bajtu, pro požadavky na rozsah) a slabé (sémantická ekvivalence, prefix W/).
- Výhoda — ETag je přesnější než Last-Modified, protože hash se mění při každé změně obsahu nezávisle na čase.
- Optimistické zamykání — přes If-Match ETag zabraňuje konfliktům Lost Update při souběžné editaci zdrojů.
- Delta synchronizace — na ETag jsou postavena synchronizační schémata, při kterých se přenášejí pouze změněné zdroje.
- Doporučení — vždy přidávejte ETag do REST API pro mobilní aplikace. Kombinujte s Last-Modified pro kompatibilitu s CDN a proxy servery.
Vyvineme mobilní aplikaci na klíč
IT Sectr vytváří aplikace pro iOS a Android pro startupy a podniky od roku 2017. Poradíme vám a navrhneme nejlepší řešení.
Přečtěte si také