Conditional GET: wat is het, mechanisme van een voorwaardelijk verzoek

Wat is Conditional GET in HTTP?

Conditional GET — is een GET-verzoek dat een of meer voorwaardelijke headers bevat, op basis waarvan de server beslist of hij een volledig antwoord of alleen de status 304 Not Modified retourneert. Het hoofddoel is het vermijden van het verzenden van het antwoordlichaam als de bron niet is gewijzigd sinds het laatste verzoek. Dit is een fundamenteel mechanisme van HTTP-caching, gedefinieerd in de RFC 7232-specificatie.

Voor mobiele applicaties is Conditional GET een van de meest effectieve manieren om netwerkverkeer te optimaliseren. Een typisch scenario: bij het openen van de applicatie stuurt de client een reeks voorwaardelijke GET-verzoeken om de feed, het profiel en de instellingen te laden. Als de gegevens niet zijn gewijzigd, ontvangt de applicatie 304 en gebruikt de lokale kopie. Dit duurt milliseconden in plaats van seconden en verbruikt geen mobiel verkeer.

Volgens Google Web Fundamentals (2025) vermindert de implementatie van voorwaardelijke GET-verzoeken in een mobiele applicatie de gemiddelde laadtijd met 40–60% voor herhaalde bezoeken en verlaagt het gegevensverbruik met 70–90% voor pagina's met zeldzame updates. Het effect is vooral merkbaar op trage verbindingen (3G, Edge), waar elke byte telt.

Hoe werkt een voorwaardelijk GET-verzoek

Het proces bestaat uit drie stappen. Eerste — de client stuurt een gewoon GET-verzoek, de server retourneert de bron samen met caching-headers (ETag, Last-Modified). Tweede — de client slaat de bron en zijn validators lokaal op. Derde — bij een herhaald verzoek stuurt de client GET met If-None-Match (voor ETag) en/of If-Modified-Since (voor Last-Modified). De server controleert de validators en antwoordt 304 als de bron niet is gewijzigd, of 200 met nieuwe gegevens.

De server gebruikt prioriteit van ETag boven Last-Modified wanneer beide headers aanwezig zijn. Dit komt doordat ETag een nauwkeurigere validatie biedt — de inhoudshash verandert bij elke wijziging, terwijl Last-Modified een resolutie van één seconde heeft. Als ETag overeenkomt, retourneert de server onmiddellijk 304, zonder Last-Modified te controleren.

Voorbeeld van een volledige Conditional GET-cyclus in de verzoekreeks:

// Stap 1: Eerste verzoek — ontvang gegevens en ETag
GET /api/profile
Response: 200 OK
ETag: "33a64df551425fcc55e"
Body: { "name": "Alice" }

// Stap 2: Herhaal verzoek — met If-None-Match
GET /api/profile
If-None-Match: "33a64df551425fcc55e"
Response: 304 Not Modified
// Antwoordlichaam ontbreekt — gebruik lokale kopie

In het tweede verzoek vergelijkt de server de ETag uit If-None-Match met de huidige hash van de bron. Bij overeenkomst wordt 304 zonder lichaam geretourneerd — de client blijft de gecachte gegevens gebruiken. Dit is de essentie van Conditional GET: minimaal verkeer met maximale actualiteit van gegevens.

Conditional GET versus gewone GET

Een gewoon GET-verzoek retourneert altijd een volledig 200 OK-antwoord met lichaam. Zelfs als de bron niet is gewijzigd, verzendt de server alle gegevens opnieuw. Dit is acceptabel voor kleine bronnen of zeldzame verzoeken, maar voor mobiele applicaties met honderden verzoeken bij elke start leidt een dergelijke aanpak tot overmatig verbruik van verkeer en batterij.

Conditional GET voegt overhead toe in de vorm van headers (meestal 50–200 bytes per verzoek), maar bespaart kilobytes en megabytes bij het 304-antwoord. Hoe groter de bron, hoe voordeliger het voorwaardelijke verzoek. Voor afbeeldingen, gegevenslijsten en JSON-documenten vanaf 10 KB is Conditional GET vanaf het eerste herhaalde verzoek rendabel.

Vergelijking van de twee benaderingen:

Implementatievoorbeelden in Kotlin

Laten we een volledige implementatie bekijken van Conditional GET in Kotlin met OkHttp en Room voor ETag-opslag. Een takenlijstapplicatie laadt taken van de server en gebruikt voorwaardelijke verzoeken om verkeer te minimaliseren. ETags worden opgeslagen in een lokale database om ze tussen sessies te bewaren.

Repository met 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() // uit lokale 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 controleert de antwoordcode: 304 betekent geen wijzigingen en de gegevens worden uit de lokale Room-cache geretourneerd. Bij 200 wordt een nieuwe ETag opgeslagen en worden de taken in de lokale database bijgewerkt. Dit patroon is de standaard voor mobiele applicaties die synchroniseren via REST API.

Toepassing van Conditional GET in mobiele ontwikkeling

Conditional GET wordt veel gebruikt in mobiele applicaties voor het optimaliseren van gegevenssynchronisatie. Belangrijkste scenario's: laden van nieuwsfeed (Twitter, Instagram bevragen periodiek de API met If-None-Match), bijwerken van gebruikersprofiel, laden van meldingenlijst en synchronisatie van taken. In elk geval kan de applicatie de actualiteit van gegevens controleren zonder ze opnieuw te laden.

Voor offline-first applicaties dient Conditional GET als de eerste fase van synchronisatie. De applicatie stuurt eerst voorwaardelijke GET-verzoeken voor alle bronnen die sinds de laatste synchronisatie lokaal zijn gewijzigd. Bronnen met 304 vereisen geen laden. Daarna stuurt de applicatie PUT/POST voor lokale wijzigingen. Een dergelijke tweefasige aanpak zorgt voor minimaal verbruik van verkeer.

In combinatie met Conflict Resolution maakt Conditional GET efficiënte detectie van conflicten mogelijk. Als de client 200 met nieuwe gegevens heeft ontvangen (bron is gewijzigd), maar de client heeft niet-verzonden lokale wijzigingen — wordt een conflict geregistreerd. De client kan LWW toepassen (lokale wijzigingen gaan verloren) of een Merge Strategy starten om lokale en externe wijzigingen samen te voegen. Volgens Meta Engineering Blog (2025) verminderde de implementatie van Conditional GET in Messenger het gemiddelde verkeersverbruik voor synchronisatie met 73%.