Conditional GET: Was es ist, der Mechanismus der bedingten Anfrage

Was ist Conditional GET in HTTP?

Conditional GET ist eine GET-Anfrage, die einen oder mehrere bedingte Header enthält, auf deren Grundlage der Server entscheidet, ob er eine vollständige Antwort oder nur den Status 304 Not Modified zurückgibt. Das Hauptziel ist es, die Übertragung des Antwortkörpers zu vermeiden, wenn sich die Ressource seit der letzten Anfrage nicht geändert hat. Dies ist ein grundlegender HTTP-Caching-Mechanismus, der in RFC 7232 definiert ist.

Für mobile Anwendungen ist Conditional GET eine der effektivsten Möglichkeiten, den Netzwerkverkehr zu optimieren. Ein typisches Szenario: Beim Öffnen der App sendet der Client eine Reihe von bedingten GET-Anfragen, um den Feed, das Profil und die Einstellungen zu laden. Wenn sich die Daten nicht geändert haben, erhält die App 304 und verwendet die lokale Kopie. Dies dauert Millisekunden statt Sekunden und verbraucht keine mobilen Daten.

Laut Google Web Fundamentals (2025) reduziert die Implementierung von bedingten GET-Anfragen in einer mobilen Anwendung die durchschnittliche Ladezeit für wiederholte Besuche um 40–60% und senkt den Verkehrsverbrauch für Seiten mit seltenen Aktualisierungen um 70–90%. Der Effekt ist besonders bei langsamen Verbindungen (3G, Edge) spürbar, wo jedes Byte zählt.

Wie funktioniert eine bedingte GET-Anfrage

Der Prozess besteht aus drei Schritten. Erster Schritt — der Client sendet eine normale GET-Anfrage, der Server gibt die Ressource zusammen mit Caching-Headern (ETag, Last-Modified) zurück. Zweiter Schritt — der Client speichert die Ressource und ihre Validatoren lokal. Dritter Schritt — bei einer wiederholten Anfrage sendet der Client einen GET mit If-None-Match (für ETag) und/oder If-Modified-Since (für Last-Modified). Der Server überprüft die Validatoren und antwortet mit 304, wenn sich die Ressource nicht geändert hat, oder mit 200 mit neuen Daten.

Der Server verwendet ETag-Priorität vor Last-Modified, wenn beide Header vorhanden sind. Dies liegt daran, dass ETag eine genauere Validierung bietet — der Inhalts-Hash ändert sich bei jeder Änderung, während Last-Modified eine Auflösung von einer Sekunde hat. Wenn der ETag übereinstimmt, gibt der Server sofort 304 zurück, ohne Last-Modified zu überprüfen.

Beispiel eines vollständigen Conditional-GET-Zyklus in einer Anfragesequenz:

// Schritt 1: Erste Anfrage — Daten und ETag abrufen
GET /api/profile
Response: 200 OK
ETag: "33a64df551425fcc55e"
Body: { "name": "Alice" }

// Schritt 2: Anfrage wiederholen — mit If-None-Match
GET /api/profile
If-None-Match: "33a64df551425fcc55e"
Response: 304 Not Modified
// Antwortkörper fehlt — lokale Kopie verwenden

In der zweiten Anfrage vergleicht der Server den ETag aus If-None-Match mit dem aktuellen Ressourcen-Hash. Bei Übereinstimmung gibt er 304 ohne Körper zurück — der Client verwendet weiterhin die zwischengespeicherten Daten. Dies ist die Essenz von Conditional GET: minimaler Verkehr bei maximaler Datenaktualität.

Conditional GET vs. normales GET

Eine normale GET-Anfrage gibt immer eine vollständige 200 OK-Antwort mit Körper zurück. Selbst wenn sich die Ressource nicht geändert hat, überträgt der Server alle Daten erneut. Dies ist für kleine Ressourcen oder seltene Anfragen akzeptabel, aber für mobile Anwendungen mit Hunderten von Anfragen bei jedem Start führt dieser Ansatz zu übermäßigem Verkehr und Batterieverbrauch.

Conditional GET fügt Overhead in Form von Headern hinzu (normalerweise 50–200 Bytes pro Anfrage), spart aber Kilobyte und Megabyte mit einer 304-Antwort. Je größer die Ressource, desto vorteilhafter die bedingte Anfrage. Für Bilder, Datenlisten und JSON-Dokumente ab 10 KB amortisiert sich Conditional GET bereits bei der ersten wiederholten Anfrage.

Vergleichende Merkmale der beiden Ansätze:

Implementierungsbeispiele in Kotlin

Betrachten wir eine vollständige Implementierung von Conditional GET in Kotlin mit OkHttp und Room zur ETag-Speicherung. Eine Aufgabenlisten-Anwendung lädt Aufgaben vom Server und verwendet bedingte Anfragen zur Minimierung des Datenverkehrs. ETags werden in einer lokalen Datenbank gespeichert, um zwischen Sitzungen zu bestehen.

Repository mit Conditional GET in Kotlin:

class TaskRepository(
    private val api: TaskApi,
    private val etagDao: EtagDao
) {
    suspend fun getTasks(): List<Task> {
        val savedEtag = etagDao.getEtag("tasks")

        val response = api.fetchTasks(
            ifNoneMatch = savedEtag
        )

        return when (response.code()) {
            304 -> taskDao.getAll() // aus lokalem Cache
            200 -> {
                response.header("ETag")?.let {
                    etagDao.saveEtag("tasks", it)
                }
                val tasks = response.body() ?: emptyList()
                taskDao.replaceAll(tasks)
                tasks
            }
            else -> throw Exception(
                "Sync failed: ${response.code()}")
        }
    }
}

TaskRepository überprüft den Antwortcode: 304 bedeutet keine Änderungen, und die Daten werden aus dem lokalen Room-Cache zurückgegeben. Bei 200 wird ein neuer ETag gespeichert und die Aufgaben werden in der lokalen Datenbank aktualisiert. Dieses Muster ist ein Standard für mobile Anwendungen mit REST-API-Synchronisierung.

Verwendung von Conditional GET in der mobilen Entwicklung

Conditional GET wird weitgehend verwendet in mobilen Anwendungen zur Optimierung der Datensynchronisierung. Hauptszenarien: Laden von Nachrichtenfeeds (Twitter, Instagram fragen regelmäßig die API mit If-None-Match ab), Aktualisieren von Benutzerprofilen, Laden von Benachrichtigungslisten und Synchronisieren von Aufgaben. In jedem Fall kann die App die Aktualität der Daten überprüfen, ohne sie erneut herunterzuladen.

Für Offline-First-Anwendungen dient Conditional GET als erste Stufe der Synchronisierung. Die App sendet zunächst bedingte GET-Anfragen für alle Ressourcen, die seit der letzten Synchronisierung lokal geändert wurden. Ressourcen mit 304 erfordern keinen Download. Danach sendet die App PUT/POST für lokale Änderungen. Dieser zweiphasige Ansatz gewährleistet minimalen Verkehrsverbrauch.

In Kombination mit Konfliktlösung ermöglicht Conditional GET eine effiziente Konflikterkennung. Wenn der Client 200 mit neuen Daten erhält (Ressource wurde geändert), aber ungesendete lokale Änderungen hat, wird ein Konflikt registriert. Der Client kann entweder LWW anwenden (lokale Änderungen gehen verloren) oder eine Merge-Strategie starten, um lokale und entfernte Änderungen zusammenzuführen. Laut Meta Engineering Blog (2025) reduzierte die Implementierung von Conditional GET in Messenger den durchschnittlichen Synchronisierungsverkehr um 73%.