ETag in Anwendungen — was es ist, Zweck und Prinzip
ETag ist ein HTTP-Antwortheader, der eine eindeutige Kennung der Ressourcenversion enthält. Der Server generiert einen ETag als Inhalts-Hash oder Versionsnummer und gibt ihn zusammen mit den Daten an den Client zurück. Bei nachfolgenden Anfragen sendet der Client diese Kennung im If-None-Match-Header, sodass der Server prüfen kann, ob sich die Ressource geändert hat. Laut MDN Web Docs, 2025 ist ETag die Grundlage des Mechanismus für bedingte GET-Anfragen in HTTP. Bedingte Anfragen mit ETag reduzieren das Datenvolumen bei der Synchronisierung mobiler Anwendungen um bis zu 90%.
Wichtige Punkte
- ETag ist ein HTTP-Header, der eine eindeutige Ressourcenversionskennung enthält, normalerweise ein Hash des Inhalts.
- If-None-Match — der Client sendet den gespeicherten ETag, der Server gibt 304 Not Modified zurück, wenn sich die Ressource nicht geändert hat.
- Datenverkehrsersparnis — bedingte Anfragen mit ETag reduzieren das Datenvolumen bei der Synchronisierung mobiler Anwendungen, da der Antworttext nicht übertragen wird.
- Starke und schwache ETags — starke unterscheiden Byte-für-Byte-Inhalt, schwache erlauben semantische Äquivalenz der Ressource.
- Verwendung — ETag wird in REST-APIs zur Datensynchronisierung, zum Caching und zur Vermeidung von Bearbeitungskonflikten verwendet.
Was ist ETag in HTTP und mobilen Anwendungen?
ETag (Entity Tag) ist ein HTTP-Header aus der Familie der bedingten Header, der zwischengespeicherte Ressourcen validiert. Der Server berechnet einen ETag als Hash (MD5, SHA-256) oder Ressourcenversionsnummer und gibt ihn als Antwort auf eine GET-Anfrage zurück. Der Client speichert den ETag zusammen mit den Daten und sendet ihn bei nachfolgenden Anfragen im If-None-Match-Header. Wenn sich der Ressourceninhalt nicht geändert hat, antwortet der Server mit einem 304 Not Modified-Status ohne Antworttext.
Für mobile Anwendungen ist ETag von entscheidender Bedeutung, da er die Menge der heruntergeladenen Daten reduziert. Bei jedem Start oder jeder Synchronisierung überprüft die App die Aktualität der Ressourcen mit einer If-None-Match-Anfrage — anstatt vollständige Daten zu laden, erhält sie einen 304 und verwendet die lokale Kopie. Laut Google Chrome Team (2024) reduziert die Verwendung von ETag in mobilen APIs die durchschnittliche Antwortgröße um 87% für Listen und 94% für einzelne Objekte.
ETag wird serverseitig generiert und kann entweder deterministisch (identisch für identischen Inhalt, nützlich für freigegebene Caches) oder pro Antwort eindeutig (für strenge Validierung) sein. In REST-APIs, die für die mobile Synchronisierung entwickelt wurden, ist die häufigste Kombination ein Inhalts-Hash und eine Datensatzversionsnummer in der Datenbank.
ETag-Typen: starke und schwache Identifikatoren
Starke ETags (strong ETag) sind Identifikatoren, die sich bei jeder Inhaltsänderung ändern, einschließlich geringfügiger (Leerzeichen, Formatierung). Format: „abc123def“ (in doppelten Anführungszeichen, ohne Präfix). Starke ETags garantieren, dass sich die Ressource Byte-für-Byte nicht geändert hat. Sie sind für Bereichsanfragen (Range requests) und zur Überprüfung der Integrität von Teildownloads obligatorisch.
Schwache ETags (weak ETag) sind Identifikatoren mit dem Präfix W/, zum Beispiel W/„abc123def“. Sie erlauben, dass die Ressource semantisch äquivalent ist, auch wenn die Byte-Darstellung unterschiedlich ist. Schwache ETags sind nützlich für Server, die dynamisch Antworten mit unterschiedlichen Leerzeichen oder Formatierungen, aber gleicher Bedeutung generieren. Schwache ETags unterstützen jedoch keine Bereichsanfragen.
Vergleich der ETag-Typen:
| Eigenschaft | Starker ETag | Schwacher ETag |
|---|---|---|
| Format | „hash“ | W/„hash“ |
| Empfindlichkeit | Byte-für-Byte | Semantisch |
| Range-Anfragen | Unterstützt | Nicht unterstützt |
| CDN-Caching | Ideal | Eingeschränkt |
| Synchronisierung | Hohe Präzision | Erlaubt Kollisionen |
ETag vs Last-Modified: was wählen
Last-Modified ist ein HTTP-Header, der Datum und Uhrzeit der letzten Ressourcenänderung angibt. Der Client sendet es im If-Modified-Since-Header zurück. Last-Modified ist einfacher zu implementieren (der Server benötigt nur ein Datum), hat aber grundlegende Einschränkungen: eine Sekundenauflösung (zwei Änderungen in derselben Sekunde sind nicht unterscheidbar) und die Unfähigkeit zu bestimmen, ob sich der Inhalt geändert hat, wenn der Zeitstempel gleich ist (z. B. nach einer Backup-Wiederherstellung).
ETag löst diese Probleme: Der Inhalts-Hash ändert sich bei jeder Änderung unabhängig von der Zeit. Daher verwenden moderne REST-APIs eine Kombination beider Header: ETag für präzise Validierung und Last-Modified für grobe CDN-Filterung. Apache HTTP Server und Nginx generieren standardmäßig beide Header für statische Dateien.
Für mobile Anwendungen mit Synchronisierung ist ETag kritischer, da er die Erkennung von Bearbeitungskonflikten ermöglicht. Wenn ein Client eine PUT-Anfrage mit If-Match: „etag“ sendet, lehnt der Server die Anfrage ab, wenn die Ressource von einem anderen Client geändert wurde (optimistische Sperrung). Last-Modified kann aufgrund der Sekundengenauigkeit eine solche Zuverlässigkeit nicht garantieren.
Beispiele für die Arbeit mit ETag in Kotlin
Sehen wir uns eine clientseitige Implementierung von ETag in einer mobilen App mit Kotlin unter Verwendung von Retrofit und OkHttp an. Bei jeder GET-Anfrage speichert der Client den ETag aus der Antwort und sendet ihn bei der nächsten Anfrage im If-None-Match-Header. Wenn der Server 304 zurückgibt, werden die Daten nicht erneut heruntergeladen.
Einrichtung des OkHttp-Clients mit ETag-Caching:
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}"))
}
}
}Der Client speichert den ETag nach einer erfolgreichen 200-Antwort und sendet ihn im If-None-Match-Header bei der nächsten Anfrage. Bei einer 304-Antwort weiß der Client, dass die lokale Version aktuell ist, und verschwendet keinen Datenverkehr für erneutes Herunterladen. Dieses Muster reduziert die Netzwerkkosten mobiler Anwendungen um 80–90% für häufig angefragte Ressourcen.
Die Rolle von ETag bei der Synchronisierung mobiler Anwendungen
ETag ist ein Schlüsselmechanismus zur Optimierung der Synchronisierung mobiler Anwendungen mit REST-APIs. Bei einem Standardsynchronisierungsschema fordert der Client zunächst eine Liste von Ressourcen mit ETag-Validierung an — wenn sich keine Ressource geändert hat, gibt der Server 304 zurück und der Client schließt die Synchronisierung ab. Wenn es Änderungen gibt, gibt der Server nur die geänderten Ressourcen zurück. Dieser Ansatz wird als Delta-Synchronisierung bezeichnet und ist für mobile Geräte mit begrenztem Datenverkehr von entscheidender Bedeutung.
In Szenarien mit optimistischer Sperrung wird ETag verwendet, um Lost-Update-Konflikte zu verhindern. Wenn ein Client eine PUT-Anfrage zum Aktualisieren einer Ressource sendet, fügt er den If-Match: „etag“-Header hinzu. Wenn der ETag nicht übereinstimmt (ein anderer Client hat die Ressource bereits geändert), antwortet der Server mit 412 Precondition Failed, und der Client muss die aktuelle Version erneut abrufen und die Änderung wiederholen. Dieser Ansatz gewährleistet Datenkonsistenz ohne Datenbanksperren.
Für verteilte Systeme mit Offline-Modus wird ETag in Kombination mit Konfliktlösung verwendet. Der Client synchronisiert, indem er aktuelle ETags für alle Ressourcen abruft. Beim Senden von Änderungen überprüft der Server If-Match — wenn der ETag nicht übereinstimmt, wird ein Konflikt registriert, der gemäß der gewählten Strategie (LWW, Merge) gelöst wird. Laut Postman API Report (2025) verwenden 67% der Produktions-REST-APIs für mobile Anwendungen ETag als primären Mechanismus zur Versionsvalidierung.
Häufig gestellte Fragen
Was ist der ETag-HTTP-Header?
ETag ist ein HTTP-Antwortheader, der eine eindeutige Ressourcenversionskennung enthält. Der Client verwendet ihn für bedingte Anfragen: Wenn sich die Ressource nicht geändert hat, gibt der Server 304 Not Modified ohne Antworttext zurück und spart so Datenverkehr.
Was ist der Unterschied zwischen ETag und Last-Modified?
ETag verwendet einen Inhalts-Hash für präzisen Vergleich. Last-Modified basiert auf dem Änderungsdatum mit Sekundengenauigkeit. ETag ist zuverlässiger für die Erkennung tatsächlicher Änderungen und unterstützt optimistische Sperrung über If-Match.
Was sind starke und schwache ETags?
Starke ETags (ohne Präfix) unterscheiden Ressourcen Byte-für-Byte. Schwache ETags (mit W/-Präfix) erlauben semantische Äquivalenz. Starke sind für Bereichsanfragen erforderlich, schwache für dynamisch generierten Inhalt.
Wie hilft ETag bei der mobilen Synchronisierung?
ETag reduziert den Datenverkehr um 80–90%: Der Client überprüft die Aktualität aller Ressourcen über If-None-Match und lädt nur die geänderten herunter. Ohne ETag würde der Client bei jeder Synchronisierung vollständige Daten herunterladen und Datenverkehr sowie Akku verschwenden.
Wie implementiert man ETag auf dem Server?
Der Server berechnet einen ETag als Hash (MD5, SHA-256) des Antwortinhalts oder verwendet eine Datensatzversionsnummer aus der Datenbank. In Spring Boot reicht die Annotation @Cacheable mit etag = true. In Express.js ist die etag-Middleware standardmäßig aktiviert.
Zusammenfassung
- ETag ist ein HTTP-Header zur Ressourcenversionsvalidierung, basierend auf einem Inhalts-Hash oder einer Versionsnummer.
- Bedingte Anfragen — der Client sendet If-None-Match mit dem gespeicherten ETag, der Server antwortet mit 304 bei Unverändertheit.
- ETag-Typen — starke (Byte-für-Byte, für Range-Anfragen) und schwache (semantische Äquivalenz, W/-Präfix).
- Vorteil — ETag ist genauer als Last-Modified, da sich der Hash bei jeder Inhaltsänderung unabhängig von der Zeit ändert.
- Optimistische Sperrung — über If-Match verhindert ETag Lost-Update-Konflikte bei gleichzeitiger Ressourcenbearbeitung.
- Delta-Synchronisierung — ETag ermöglicht Synchronisierungsschemata, bei denen nur geänderte Ressourcen übertragen werden.
- Empfehlung — fügen Sie ETag immer zu REST-APIs für mobile Anwendungen hinzu. Kombinieren Sie es mit Last-Modified für CDN- und Proxy-Server-Kompatibilität.
Wir entwickeln eine mobile Applikation schlüsselfertig
IT Sectr entwickelt seit 2017 iOS- und Android-Apps für Startups und Unternehmen. Wir beraten Sie und schlagen die beste Lösung vor.
Lesen Sie auch