Conditional GET: czym jest, mechanizm żądania warunkowego

Czym jest Conditional GET w HTTP?

Conditional GET — to żądanie GET zawierające jeden lub więcej nagłówków warunkowych, na podstawie których serwer decyduje, czy zwrócić pełną odpowiedź, czy tylko status 304 Not Modified. Głównym celem jest uniknięcie przesyłania treści odpowiedzi, jeśli zasób nie zmienił się od ostatniego żądania. To fundamentalny mechanizm buforowania HTTP, zdefiniowany w specyfikacji RFC 7232.

Dla aplikacji mobilnych Conditional GET to jeden z najskuteczniejszych sposobów optymalizacji ruchu sieciowego. Typowy scenariusz: przy otwieraniu aplikacji klient wysyła serię warunkowych żądań GET w celu załadowania kanału, profilu i ustawień. Jeśli dane się nie zmieniły, aplikacja otrzymuje 304 i korzysta z lokalnej kopii. Zajmuje to milisekundy zamiast sekund i nie zużywa transferu mobilnego.

Według Google Web Fundamentals (2025), wdrożenie warunkowych żądań GET w aplikacji mobilnej skraca średni czas ładowania o 40–60% dla ponownych odwiedzin i zmniejsza zużycie transferu o 70–90% dla stron z rzadkimi aktualizacjami. Efekt jest szczególnie widoczny przy wolnych połączeniach (3G, Edge), gdzie liczy się każdy bajt.

Jak działa warunkowe żądanie GET

Proces składa się z trzech kroków. Pierwszy — klient wysyła zwykłe żądanie GET, serwer zwraca zasób wraz z nagłówkami buforowania (ETag, Last-Modified). Drugi — klient zapisuje zasób i jego walidatory lokalnie. Trzeci — przy ponownym żądaniu klient wysyła GET z If-None-Match (dla ETag) i/lub If-Modified-Since (dla Last-Modified). Serwer sprawdza walidatory i odpowiada 304, jeśli zasób się nie zmienił, albo 200 z nowymi danymi.

Serwer używa priorytetu ETag nad Last-Modified przy obecności obu nagłówków. Wynika to z faktu, że ETag zapewnia dokładniejszą walidację — skrót zawartości zmienia się przy każdej modyfikacji, podczas gdy Last-Modified ma rozdzielczość jednej sekundy. Jeśli ETag jest zgodny, serwer natychmiast zwraca 304, nie sprawdzając Last-Modified.

Przykład pełnego cyklu Conditional GET w sekwencji żądań:

// Krok 1: Pierwsze żądanie — pobierz dane i ETag
GET /api/profile
Response: 200 OK
ETag: "33a64df551425fcc55e"
Body: { "name": "Alice" }

// Krok 2: Powtórz żądanie — z If-None-Match
GET /api/profile
If-None-Match: "33a64df551425fcc55e"
Response: 304 Not Modified
// Treść odpowiedzi jest nieobecna — użyj lokalnej kopii

W drugim żądaniu serwer porównuje ETag z If-None-Match z bieżącym skrótem zasobu. Przy zgodności zwracane jest 304 bez treści — klient kontynuuje korzystanie z buforowanych danych. To jest istota Conditional GET: minimum ruchu przy maksymalnej aktualności danych.

Conditional GET a zwykłe GET

Zwykłe żądanie GET zawsze zwraca pełną odpowiedź 200 OK z treścią. Nawet jeśli zasób się nie zmienił, serwer przesyła wszystkie dane od nowa. Jest to akceptowalne dla małych zasobów lub przy rzadkich żądaniach, ale dla aplikacji mobilnych z setkami żądań przy każdym uruchomieniu takie podejście prowadzi do nadmiernego zużycia transferu i baterii.

Conditional GET dodaje narzut w postaci nagłówków (zazwyczaj 50–200 bajtów na żądanie), ale oszczędza kilobajty i megabajty przy odpowiedzi 304. Im większy zasób, tym bardziej opłaca się żądanie warunkowe. Dla obrazów, list danych i dokumentów JSON o rozmiarze od 10 KB Conditional GET zwraca się już przy pierwszym ponownym żądaniu.

Porównanie obu podejść:

Przykłady implementacji w Kotlin

Rozważmy pełną implementację Conditional GET w Kotlin z użyciem OkHttp i Room do przechowywania ETag. Aplikacja listy zadań ładuje zadania z serwera i używa warunkowych żądań w celu minimalizacji ruchu. ETag są przechowywane w lokalnej bazie danych, aby zachować je między sesjami.

Repozytorium z Conditional GET w 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() // z lokalnego bufora
            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 sprawdza kod odpowiedzi: 304 oznacza brak zmian, a dane są zwracane z lokalnego bufora Room. Przy 200 nowy ETag jest zapisywany, a zadania aktualizowane w lokalnej bazie. Ten wzorzec to standard dla aplikacji mobilnych synchronizujących się przez REST API.

Zastosowanie Conditional GET w programowaniu mobilnym

Conditional GET jest szeroko stosowany w aplikacjach mobilnych do optymalizacji synchronizacji danych. Główne scenariusze: ładowanie kanału wiadomości (Twitter, Instagram okresowo odpytywa API z If-None-Match), aktualizacja profilu użytkownika, ładowanie listy powiadomień i synchronizacja zadań. W każdym przypadku aplikacja może sprawdzać aktualność danych bez ponownego ich pobierania.

Dla aplikacji offline-first Conditional GET służy jako pierwszy etap synchronizacji. Aplikacja najpierw wysyła warunkowe żądania GET dla wszystkich zasobów, które zostały zmodyfikowane lokalnie od ostatniej synchronizacji. Zasoby z 304 nie wymagają pobierania. Następnie aplikacja wysyła PUT/POST dla lokalnych zmian. Takie dwufazowe podejście zapewnia minimalne zużycie transferu.

W połączeniu z Conflict Resolution Conditional GET pozwala skutecznie wykrywać konflikty. Jeśli klient otrzymał 200 z nowymi danymi (zasób się zmienił), ale klient ma niewysłane lokalne zmiany — rejestrowany jest konflikt. Klient może zastosować LWW (zmiany lokalne są tracone) lub uruchomić Merge Strategy w celu połączenia lokalnych i zdalnych zmian. Według Meta Engineering Blog (2025), wdrożenie Conditional GET w Messenger zmniejszyło średnie zużycie transferu przy synchronizacji o 73%.