Conditional GET: mi ez, a feltételes kérés mechanizmusa

Mi a Conditional GET a HTTP-ben?

Conditional GET — egy GET kérés, amely egy vagy több feltételes fejlécet tartalmaz, amelyek alapján a szerver eldönti, hogy teljes választ vagy csak 304 Not Modified státuszt küldjön vissza. A fő cél a választest elküldésének elkerülése, ha az erőforrás nem változott az utolsó kérés óta. Ez a HTTP-gyorsítótárazás alapvető mechanizmusa, amelyet az RFC 7232 specifikáció határoz meg.

Mobil alkalmazások számára a Conditional GET az egyik leghatékonyabb módja a hálózati forgalom optimalizálásának. Tipikus forgatókönyv: az alkalmazás megnyitásakor az ügyfél egy sor feltételes GET kérést küld a hírfolyam, profil és beállítások betöltéséhez. Ha az adatok nem változtak, az alkalmazás 304-et kap és a helyi másolatot használja. Ez másodpercek helyett ezredmásodpercekig tart, és nem fogyaszt mobil adatforgalmat.

A Google Web Fundamentals (2025) szerint a feltételes GET kérések bevezetése egy mobil alkalmazásban 40–60%-kal csökkenti az átlagos betöltési időt ismételt látogatások esetén, és 70–90%-kal mérsékli az adatforgalmat a ritkán frissülő oldalaknál. A hatás különösen lassú kapcsolatoknál (3G, Edge) észlelhető, ahol minden byte számít.

Hogyan működik a feltételes GET kérés

A folyamat három lépésből áll. Első — az ügyfél egy szokásos GET kérést küld, a szerver visszaadja az erőforrást a gyorsítótárazási fejlécekkel (ETag, Last-Modified) együtt. Második — az ügyfél helyileg elmenti az erőforrást és annak érvényesítőit. Harmadik — ismételt kéréskor az ügyfél GET-et küld If-None-Match (ETag-hoz) és/vagy If-Modified-Since (Last-Modified-hez) fejlécekkel. A szerver ellenőrzi az érvényesítőket, és 304-gyel válaszol, ha az erőforrás nem változott, vagy 200-zal új adatokkal.

A szerver az ETag elsőbbségét használja a Last-Modified-dal szemben, ha mindkét fejléc jelen van. Ez azért van, mert az ETag pontosabb érvényesítést biztosít — a tartalom hash-je minden változáskor módosul, míg a Last-Modified felbontása egy másodperc. Ha az ETag egyezik, a szerver azonnal 304-et küld vissza, anélkül hogy ellenőrizné a Last-Modified-t.

Példa a Conditional GET teljes ciklusára a kérések sorrendjében:

// 1. lépés: Első kérés — adatok és ETag lekérése
GET /api/profile
Response: 200 OK
ETag: "33a64df551425fcc55e"
Body: { "name": "Alice" }

// 2. lépés: Kérés megismétlése — If-None-Match-al
GET /api/profile
If-None-Match: "33a64df551425fcc55e"
Response: 304 Not Modified
// A választest hiányzik — használja a helyi másolatot

A második kérésben a szerver összehasonlítja az If-None-Match-ból származó ETag-ot az erőforrás aktuális hash-jével. Egyezés esetén 304 kerül visszaküldésre test nélkül — az ügyfél folytatja a gyorsítótárazott adatok használatát. Ez a Conditional GET lényege: minimális forgalom maximális adatfrissesség mellett.

Conditional GET a szokásos GET-tel szemben

A szokásos GET kérés mindig teljes 200 OK választ ad vissza testtel. Még ha az erőforrás nem is változott, a szerver újra elküldi az összes adatot. Ez elfogadható kis erőforrások vagy ritka kérések esetén, de a mobil alkalmazásoknál, amelyek minden indításkor több száz kérést küldenek, ez a megközelítés túlzott adat- és akkumulátorfogyasztáshoz vezet.

Conditional GET többletterhelést ad a fejlécek formájában (általában 50–200 byte kérésenként), de kilobyte-okat és megabyte-okat takarít meg a 304-es válasznál. Minél nagyobb az erőforrás, annál előnyösebb a feltételes kérés. Képek, adatlisták és JSON dokumentumok esetén 10 KB-tól a Conditional GET az első ismételt kérésnél megtérül.

A két megközelítés összehasonlítása:

Implementációs példák Kotlinban

Vizsgáljuk meg egy teljes implementációt a Conditional GET-ről Kotlinban OkHttp és Room használatával az ETag tárolására. Egy feladatlista alkalmazás betölti a feladatokat a szerverről, és feltételes kéréseket használ a forgalom minimalizálására. Az ETag-ok helyi adatbázisban tárolódnak a munkamenetek közötti megőrzés érdekében.

Repository Conditional GET-tel Kotlinban:

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() // a helyi gyorsítótárból
            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 ellenőrzi a válaszkódot: a 304 változás hiányát jelenti, és az adatok a Room helyi gyorsítótárából kerülnek visszaadásra. 200 esetén az új ETag elmentésre kerül, és a feladatok frissülnek a helyi adatbázisban. Ez a minta a REST API-n keresztül szinkronizáló mobil alkalmazások szabványa.

A Conditional GET alkalmazása a mobilfejlesztésben

A Conditional GET széles körben használatos mobil alkalmazásokban az adatszinkronizálás optimalizálására. Fő forgatókönyvek: hírfolyam betöltése (Twitter, Instagram periodikusan lekérdezi az API-t If-None-Match-al), felhasználói profil frissítése, értesítési lista betöltése és feladatok szinkronizálása. Minden esetben az alkalmazás ellenőrizheti az adatok frissességét anélkül, hogy újratöltené azokat.

Offline-first alkalmazások számára a Conditional GET a szinkronizálás első fázisaként szolgál. Az alkalmazás először feltételes GET kéréseket küld minden olyan erőforrásra, amely az utolsó szinkronizálás óta helyileg módosult. A 304-es erőforrások nem igényelnek betöltést. Ezt követően az alkalmazás PUT/POST kéréseket küld a helyi változtatásokhoz. Ez a kétfázisú megközelítés minimális adatforgalmat biztosít.

A Conflict Resolution kombinációjával a Conditional GET lehetővé teszi az ütközések hatékony észlelését. Ha az ügyfél 200-at kapott új adatokkal (az erőforrás megváltozott), de az ügyfélnek elküldetlen helyi változtatásai vannak — ütközés kerül rögzítésre. Az ügyfél alkalmazhat LWW-t (a helyi változtatások elvesznek) vagy elindíthat egy Merge Strategy-t a helyi és távoli változtatások egyesítésére. A Meta Engineering Blog (2025) szerint a Conditional GET bevezetése a Messengerben 73%-kal csökkentette az átlagos adatforgalmat a szinkronizálás során.