Conditional GET: vad det är, mekanism för villkorlig begäran

Vad är Conditional GET i HTTP?

Conditional GET — är en GET-begäran som innehåller en eller flera villkorliga rubriker, baserat på vilka servern bestämmer om den ska returnera ett fullständigt svar eller endast status 304 Not Modified. Huvudmålet är att undvika överföring av svarskroppen om resursen inte har ändrats sedan den senaste begäran. Detta är en grundläggande HTTP-cachingmekanism, definierad i RFC 7232-specifikationen.

För mobila applikationer är Conditional GET ett av de mest effektiva sätten att optimera nätverkstrafik. Ett typiskt scenario: när applikationen öppnas skickar klienten en serie villkorliga GET-begäranden för att ladda flöde, profil och inställningar. Om data inte har ändrats får applikationen 304 och använder en lokal kopia. Detta tar millisekunder istället för sekunder och förbrukar ingen mobildata.

Enligt Google Web Fundamentals (2025) minskar implementering av villkorliga GET-begäranden i en mobil applikation den genomsnittliga laddningstiden med 40–60 % för återkommande besök och minskar dataförbrukningen med 70–90 % för sidor med sällsynta uppdateringar. Effekten är särskilt märkbar på långsamma anslutningar (3G, Edge), där varje byte räknas.

Hur fungerar en villkorlig GET-begäran

Processen består av tre steg. Första — klienten skickar en vanlig GET-begäran, servern returnerar resursen tillsammans med caching-rubriker (ETag, Last-Modified). Andra — klienten sparar resursen och dess validerare lokalt. Tredje — vid en upprepad begäran skickar klienten GET med If-None-Match (för ETag) och/eller If-Modified-Since (för Last-Modified). Servern kontrollerar validerarna och svarar 304 om resursen inte har ändrats, eller 200 med ny data.

Servern använder prioritet för ETag framför Last-Modified när båda rubrikerna är närvarande. Detta beror på att ETag ger mer exakt validering — innehållshash ändras vid varje förändring, medan Last-Modified har en upplösning på en sekund. Om ETag matchar returnerar servern omedelbart 304 utan att kontrollera Last-Modified.

Exempel på en fullständig Conditional GET-cykel i begärandesekvensen:

// Steg 1: Första begäran — hämta data och ETag
GET /api/profile
Response: 200 OK
ETag: "33a64df551425fcc55e"
Body: { "name": "Alice" }

// Steg 2: Upprepa begäran — med If-None-Match
GET /api/profile
If-None-Match: "33a64df551425fcc55e"
Response: 304 Not Modified
// Svarskroppen saknas — använd lokal kopia

I den andra begäran jämför servern ETag från If-None-Match med resursens aktuella hash. Vid matchning returneras 304 utan kropp — klienten fortsätter att använda cachad data. Detta är kärnan i Conditional GET: minimal trafik med maximal dataaktuallitet.

Conditional GET jämfört med vanlig GET

En vanlig GET-begäran returnerar alltid ett fullständigt 200 OK-svar med kropp. Även om resursen inte har ändrats överför servern all data på nytt. Detta är acceptabelt för små resurser eller sällsynta begäranden, men för mobila applikationer med hundratals begäranden vid varje start leder en sådan metod till överdriven data- och batteriförbrukning.

Conditional GET lägger till overhead i form av rubriker (vanligtvis 50–200 byte per begäran), men sparar kilobyte och megabyte vid 304-svar. Ju större resursen är, desto mer fördelaktig är den villkorliga begäran. För bilder, datalistor och JSON-dokument från 10 KB och uppåt betalar sig Conditional GET från den första upprepade begäran.

Jämförelse av de två metoderna:

Implementeringsexempel i Kotlin

Låt oss titta på en fullständig implementering av Conditional GET i Kotlin med OkHttp och Room för ETag-lagring. En uppgiftslista-applikation laddar uppgifter från servern och använder villkorliga begäranden för att minimera trafik. ETag lagras i en lokal databas för att bevaras mellan sessioner.

Repository med Conditional GET i 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() // från lokal 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 kontrollerar svarskoden: 304 betyder inga ändringar och data returneras från Room:s lokala cache. Vid 200 sparas den nya ETag och uppgifterna uppdateras i den lokala databasen. Detta mönster är standard för mobila applikationer som synkroniseras via REST API.

Tillämpning av Conditional GET i mobilutveckling

Conditional GET används brett i mobila applikationer för att optimera datasynkronisering. Huvudscenarier: laddning av nyhetsflöde (Twitter, Instagram frågar periodvis API med If-None-Match), uppdatering av användarprofil, laddning av notifikationslista och synkronisering av uppgifter. I varje fall kan applikationen kontrollera dataaktuallitet utan att ladda om den.

För offline-first-applikationer fungerar Conditional GET som den första fasen av synkronisering. Applikationen skickar först villkorliga GET-begäranden för alla resurser som har ändrats lokalt sedan senaste synkroniseringen. Resurser med 304 kräver ingen inläsning. Därefter skickar applikationen PUT/POST för lokala ändringar. En sådan tvåfas-metod säkerställer minimal dataförbrukning.

I kombination med Conflict Resolution möjliggör Conditional GET effektiv detektering av konflikter. Om klienten fick 200 med ny data (resursen har ändrats), men klienten har oskickade lokala ändringar — registreras en konflikt. Klienten kan tillämpa LWW (lokala ändringar går förlorade) eller starta en Merge Strategy för att sammanfoga lokala och fjärranslutna ändringar. Enligt Meta Engineering Blog (2025) minskade implementeringen av Conditional GET i Messenger den genomsnittliga dataförbrukningen för synkronisering med 73 %.