Conditional GET: cosa è, il meccanismo di richiesta condizionale

Cos’è Conditional GET in HTTP?

Conditional GET è una richiesta GET che include una o più intestazioni condizionali, in base alle quali il server decide se restituire una risposta completa o solo lo stato 304 Not Modified. L’obiettivo principale è evitare la trasmissione del corpo della risposta se la risorsa non è cambiata dall’ultima richiesta. Questo è un meccanismo fondamentale di caching HTTP definito in RFC 7232.

Per le applicazioni mobili, Conditional GET è uno dei modi più efficaci per ottimizzare il traffico di rete. Uno scenario tipico: all’apertura dell’app, il client invia una serie di richieste GET condizionali per caricare il feed, il profilo e le impostazioni. Se i dati non sono cambiati, l’app riceve 304 e utilizza la copia locale. Questo richiede millisecondi anziché secondi e non consuma dati mobili.

Secondo Google Web Fundamentals (2025), l’implementazione di richieste GET condizionali in un’applicazione mobile riduce il tempo di caricamento medio del 40–60% per le visite ripetute e diminuisce l’utilizzo del traffico del 70–90% per le pagine con aggiornamenti poco frequenti. L’effetto è particolarmente evidente su connessioni lente (3G, Edge), dove ogni byte conta.

Come funziona una richiesta GET condizionale

Il processo si compone di tre fasi. Prima — il client invia una richiesta GET normale, il server restituisce la risorsa insieme alle intestazioni di cache (ETag, Last-Modified). Seconda — il client salva la risorsa e i suoi validatori localmente. Terza — su una richiesta ripetuta, il client invia un GET con If-None-Match (per ETag) e/o If-Modified-Since (per Last-Modified). Il server controlla i validatori e risponde 304 se la risorsa non è cambiata, o 200 con nuovi dati.

Il server utilizza la priorità di ETag su Last-Modified quando entrambe le intestazioni sono presenti. Ciò è dovuto al fatto che ETag fornisce una validazione più precisa — l’hash del contenuto cambia con qualsiasi modifica, mentre Last-Modified ha una risoluzione di un secondo. Se l’ETag corrisponde, il server restituisce immediatamente 304 senza controllare Last-Modified.

Esempio di un ciclo completo di Conditional GET in una sequenza di richieste:

// Fase 1: Prima richiesta — ottenere dati e ETag
GET /api/profile
Response: 200 OK
ETag: "33a64df551425fcc55e"
Body: { "name": "Alice" }

// Fase 2: Ripetere la richiesta — con If-None-Match
GET /api/profile
If-None-Match: "33a64df551425fcc55e"
Response: 304 Not Modified
// Corpo della risposta assente — usare copia locale

Nella seconda richiesta, il server confronta l’ETag di If-None-Match con l’hash corrente della risorsa. Se corrispondono, restituisce 304 senza corpo — il client continua a utilizzare i dati nella cache. Questa è l’essenza di Conditional GET: traffico minimo con massima attualità dei dati.

Conditional GET vs GET normale

Una richiesta GET normale restituisce sempre una risposta completa 200 OK con corpo. Anche se la risorsa non è cambiata, il server trasmette nuovamente tutti i dati. Ciò è accettabile per risorse piccole o richieste poco frequenti, ma per applicazioni mobili con centinaia di richieste a ogni avvio, questo approccio porta a un consumo eccessivo di traffico e batteria.

Conditional GET aggiunge un sovraccarico sotto forma di intestazioni (di solito 50–200 byte per richiesta) ma risparmia kilobyte e megabyte con una risposta 304. Più grande è la risorsa, più vantaggiosa è la richiesta condizionale. Per immagini, elenchi di dati e documenti JSON da 10 KB in su, Conditional GET si ripaga dalla prima richiesta ripetuta.

Caratteristiche comparative dei due approcci:

Esempi di implementazione in Kotlin

Vediamo un’implementazione completa di Conditional GET in Kotlin utilizzando OkHttp e Room per l’archiviazione di ETag. Un’applicazione di elenco attività carica le attività dal server e utilizza richieste condizionali per ridurre al minimo il traffico. Gli ETag vengono archiviati in un database locale per persistere tra le sessioni.

Repository con Conditional GET in 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() // dalla cache locale
            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 controlla il codice di risposta: 304 significa nessuna modifica e i dati vengono restituiti dalla cache locale di Room. In caso di 200, un nuovo ETag viene salvato e le attività vengono aggiornate nel database locale. Questo modello è uno standard per le applicazioni mobili con sincronizzazione tramite API REST.

Utilizzo di Conditional GET nello sviluppo mobile

Conditional GET è ampiamente utilizzato nelle applicazioni mobili per l’ottimizzazione della sincronizzazione dei dati. Scenari principali: caricamento dei feed di notizie (Twitter, Instagram interrogano periodicamente l’API con If-None-Match), aggiornamento dei profili utente, caricamento degli elenchi di notifiche e sincronizzazione delle attività. In ogni caso, l’app può verificare l’attualità dei dati senza scaricarli nuovamente.

Per le applicazioni offline-first, Conditional GET funge da primo stadio della sincronizzazione. L’app invia prima richieste GET condizionali per tutte le risorse che sono state modificate localmente dall’ultima sincronizzazione. Le risorse con 304 non richiedono download. Dopodiché, l’app invia PUT/POST per le modifiche locali. Questo approccio a due fasi garantisce un consumo minimo di traffico.

In combinazione con la Risoluzione dei conflitti, Conditional GET consente un’efficiente rilevazione dei conflitti. Se il client riceve 200 con nuovi dati (la risorsa è cambiata) ma ha modifiche locali non inviate — viene registrato un conflitto. Il client può applicare LWW (le modifiche locali vengono perse) o avviare una Strategia di unione per unire le modifiche locali e remote. Secondo Meta Engineering Blog (2025), l’implementazione di Conditional GET in Messenger ha ridotto il traffico di sincronizzazione medio del 73%.