Conditional GET: co to je, mechanismus podmíněného požadavku

Co je Conditional GET v HTTP?

Conditional GET — je požadavek GET obsahující jednu nebo více podmíněných hlaviček, na základě kterých server rozhodne, zda vrátí úplnou odpověď nebo pouze status 304 Not Modified. Hlavním cílem je vyhnout se přenosu těla odpovědi, pokud se zdroj od posledního požadavku nezměnil. Jedná se o základní mechanismus HTTP cache, definovaný ve specifikaci RFC 7232.

Pro mobilní aplikace je Conditional GET jedním z nejefektivnějších způsobů optimalizace síťového provozu. Typický scénář: při otevření aplikace klient odešle sérii podmíněných GET požadavků pro načtení kanálu, profilu a nastavení. Pokud se data nezměnila, aplikace obdrží 304 a použije lokální kopii. To trvá milisekundy místo sekund a nespotřebovává mobilní data.

Podle Google Web Fundamentals (2025) implementace podmíněných GET požadavků v mobilní aplikaci snižuje průměrnou dobu načítání o 40–60 % pro opakované návštěvy a snižuje spotřebu dat o 70–90 % pro stránky se vzácnými aktualizacemi. Efekt je zvláště patrný na pomalých připojeních (3G, Edge), kde záleží na každém byte.

Jak funguje podmíněný požadavek GET

Proces se skládá ze tří kroků. První — klient odešle běžný GET požadavek, server vrátí zdroj spolu s hlavičkami cache (ETag, Last-Modified). Druhý — klient uloží zdroj a jeho validátory lokálně. Třetí — při opakovaném požadavku klient odešle GET s If-None-Match (pro ETag) a/nebo If-Modified-Since (pro Last-Modified). Server zkontroluje validátory a odpoví 304, pokud se zdroj nezměnil, nebo 200 s novými daty.

Server používá prioritu ETag před Last-Modified, pokud jsou přítomny obě hlavičky. To je proto, že ETag poskytuje přesnější validaci — hash obsahu se mění při každé změně, zatímco Last-Modified má rozlišení jedné sekundy. Pokud se ETag shoduje, server okamžitě vrátí 304, aniž by kontroloval Last-Modified.

Příklad úplného cyklu Conditional GET v sekvenci požadavků:

// Krok 1: První požadavek — získání dat a ETag
GET /api/profile
Response: 200 OK
ETag: "33a64df551425fcc55e"
Body: { "name": "Alice" }

// Krok 2: Opakování požadavku — s If-None-Match
GET /api/profile
If-None-Match: "33a64df551425fcc55e"
Response: 304 Not Modified
// Tělo odpovědi chybí — použijte lokální kopii

Ve druhém požadavku server porovná ETag z If-None-Match s aktuálním hashem zdroje. Při shodě je vráceno 304 bez těla — klient pokračuje v používání dat z mezipaměti. To je podstata Conditional GET: minimální provoz při maximální aktuálnosti dat.

Conditional GET versus běžné GET

Běžný GET požadavek vždy vrací úplnou odpověď 200 OK s tělem. I když se zdroj nezměnil, server znovu přenáší všechna data. To je přijatelné pro malé zdroje nebo vzácné požadavky, ale pro mobilní aplikace se stovkami požadavků při každém spuštění takový přístup vede k nadměrné spotřebě dat a baterie.

Conditional GET přidává režii ve formě hlaviček (obvykle 50–200 bajtů na požadavek), ale šetří kilobyty a megabyty při odpovědi 304. Čím větší je zdroj, tím výhodnější je podmíněný požadavek. Pro obrázky, seznamy dat a JSON dokumenty od 10 KB výše se Conditional GET zaplatí od prvního opakovaného požadavku.

Srovnání obou přístupů:

Příklady implementace v Kotlinu

Podívejme se na kompletní implementaci Conditional GET v Kotlinu s použitím OkHttp a Room pro ukládání ETag. Aplikace seznamu úkolů načítá úkoly ze serveru a používá podmíněné požadavky k minimalizaci provozu. ETagy jsou ukládány v lokální databázi pro zachování mezi relacemi.

Repozitář s Conditional GET v Kotlinu:

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() // z lokální mezipaměti
            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 kontroluje kód odpovědi: 304 znamená žádné změny a data jsou vrácena z lokální cache Room. Při 200 je nový ETag uložen a úkoly jsou aktualizovány v lokální databázi. Tento vzor je standardem pro mobilní aplikace synchronizující se přes REST API.

Použití Conditional GET ve vývoji mobilních aplikací

Conditional GET je široce používán v mobilních aplikacích pro optimalizaci synchronizace dat. Hlavní scénáře: načítání zpravodajského kanálu (Twitter, Instagram periodicky dotazují API s If-None-Match), aktualizace uživatelského profilu, načítání seznamu oznámení a synchronizace úkolů. V každém případě může aplikace zkontrolovat aktuálnost dat bez jejich opětovného načítání.

Pro offline-first aplikace slouží Conditional GET jako první fáze synchronizace. Aplikace nejprve odešle podmíněné GET požadavky pro všechny zdroje, které byly lokálně změněny od poslední synchronizace. Zdroje s 304 nevyžadují načítání. Poté aplikace odešle PUT/POST pro lokální změny. Tento dvoufázový přístup zajišťuje minimální spotřebu dat.

V kombinaci s Conflict Resolution umožňuje Conditional GET efektivní detekci konfliktů. Pokud klient obdržel 200 s novými daty (zdroj se změnil), ale klient má neodeslané lokální změny — je zaznamenán konflikt. Klient může použít LWW (lokální změny jsou ztraceny) nebo spustit Merge Strategy pro sloučení lokálních a vzdálených změn. Podle Meta Engineering Blog (2025) implementace Conditional GET v Messengeru snížila průměrnou spotřebu dat při synchronizaci o 73 %.