Conditional GET: ce este, mecanismul cererii condiționate

Ce este Conditional GET în HTTP?

Conditional GET — este o cerere GET care conține unul sau mai multe anteturi condiționate, pe baza cărora serverul decide să returneze răspunsul complet sau doar statusul 304 Not Modified. Scopul principal este evitarea transmiterii corpului răspunsului, dacă resursa nu s-a modificat de la ultima cerere. Acesta este un mecanism fundamental al cache-ului HTTP, definit în specificația RFC 7232.

Pentru aplicațiile mobile, Conditional GET este una dintre cele mai eficiente metode de optimizare a traficului de rețea. Scenariul tipic: la deschiderea aplicației, clientul trimite o serie de cereri GET condiționate pentru încărcarea fluxului, profilului și setărilor. Dacă datele nu s-au modificat, aplicația primește 304 și folosește copia locală. Aceasta durează milisecunde în loc de secunde și nu consumă trafic mobil.

Conform Google Web Fundamentals (2025), implementarea cererilor GET condiționate într-o aplicație mobilă reduce timpul mediu de încărcare cu 40–60% pentru vizitele repetate și scade consumul de trafic cu 70–90% pentru paginile cu actualizări rare. Efectul este deosebit de vizibil pe conexiunile lente (3G, Edge), unde fiecare byte contează.

Cum funcționează cererea GET condiționată

Procesul constă în trei pași. Primul — clientul trimite o cerere GET obișnuită, serverul returnează resursa împreună cu anteturile de cache (ETag, Last-Modified). Al doilea — clientul salvează resursa și validatorii săi local. Al treilea — la cererea repetată, clientul trimite GET cu If-None-Match (pentru ETag) și/sau If-Modified-Since (pentru Last-Modified). Serverul verifică validatorii și răspunde cu 304 dacă resursa nu s-a modificat, sau 200 cu date noi.

Serverul folosește prioritatea ETag față de Last-Modified când ambele anteturi sunt prezente. Acest lucru se datorează faptului că ETag asigură o validare mai precisă — hash-ul conținutului se modifică la orice schimbare, în timp ce Last-Modified are o rezoluție de o secundă. Dacă ETag se potrivește, serverul returnează imediat 304, fără a verifica Last-Modified.

Exemplu de ciclu complet Conditional GET în secvența cererilor:

// Pasul 1: Prima cerere — obțineți datele și ETag-ul
GET /api/profile
Response: 200 OK
ETag: "33a64df551425fcc55e"
Body: { "name": "Alice" }

// Pasul 2: Repetați cererea — cu If-None-Match
GET /api/profile
If-None-Match: "33a64df551425fcc55e"
Response: 304 Not Modified
// Corpul răspunsului lipsește — folosiți copia locală

În a doua cerere, serverul compară ETag-ul din If-None-Match cu hash-ul curent al resursei. La potrivire, se returnează 304 fără corp — clientul continuă să folosească datele din cache. Aceasta este esența Conditional GET: trafic minim cu actualitate maximă a datelor.

Conditional GET versus GET obișnuit

Cererea GET obișnuită returnează întotdeauna un răspuns complet 200 OK cu corp. Chiar dacă resursa nu s-a modificat, serverul transmite toate datele din nou. Acest lucru este acceptabil pentru resurse mici sau cereri rare, dar pentru aplicațiile mobile cu sute de cereri la fiecare pornire, o astfel de abordare duce la consum excesiv de trafic și baterie.

Conditional GET adaugă un overhead sub formă de anteturi (de obicei 50–200 de bytes per cerere), dar economisește kilobytes și megabytes la răspunsul 304. Cu cât resursa este mai mare, cu atât cererea condiționată este mai avantajoasă. Pentru imagini, liste de date și documente JSON de la 10 KB în sus, Conditional GET se amortizează de la prima cerere repetată.

Comparația celor două abordări:

Exemple de implementare în Kotlin

Să examinăm o implementare completă a Conditional GET în Kotlin folosind OkHttp și Room pentru stocarea ETag. O aplicație de listă de sarcini încarcă sarcinile de pe server și folosește cereri condiționate pentru a minimiza traficul. ETag-urile sunt stocate în baza de date locală pentru a fi păstrate între sesiuni.

Repository cu Conditional GET în 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() // din cache-ul local
            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 verifică codul răspunsului: 304 înseamnă nicio modificare, iar datele sunt returnate din cache-ul local Room. La 200, noul ETag este salvat, iar sarcinile sunt actualizate în baza locală. Acest model este standardul pentru aplicațiile mobile care se sincronizează prin REST API.

Aplicarea Conditional GET în dezvoltarea mobilă

Conditional GET este utilizat pe scară largă în aplicațiile mobile pentru optimizarea sincronizării datelor. Scenariile principale: încărcarea fluxului de știri (Twitter, Instagram interoghează periodic API cu If-None-Match), actualizarea profilului utilizatorului, încărcarea listei de notificări și sincronizarea sarcinilor. În fiecare caz, aplicația poate verifica actualitatea datelor fără a le reîncărca.

Pentru aplicațiile offline-first, Conditional GET servește ca primă etapă a sincronizării. Aplicația trimite mai întâi cereri GET condiționate pentru toate resursele care au fost modificate local de la ultima sincronizare. Resursele cu 304 nu necesită încărcare. După aceea, aplicația trimite PUT/POST pentru modificările locale. O astfel de abordare în două faze asigură un consum minim de trafic.

În combinație cu Conflict Resolution, Conditional GET permite detectarea eficientă a conflictelor. Dacă clientul a primit 200 cu date noi (resursa s-a modificat), dar clientul are modificări locale netrimise — se înregistrează un conflict. Clientul poate aplica LWW (modificările locale se pierd) sau poate lansa Merge Strategy pentru a îmbina modificările locale și cele de la distanță. Conform Meta Engineering Blog (2025), implementarea Conditional GET în Messenger a redus consumul mediu de trafic la sincronizare cu 73%.