Conditional GET : ce que c’est, le mécanisme de requête conditionnelle

Qu’est-ce que Conditional GET en HTTP ?

Conditional GET est une requête GET qui inclut un ou plusieurs en-têtes conditionnels, sur la base desquels le serveur décide s’il doit retourner une réponse complète ou seulement le statut 304 Not Modified. L’objectif principal est d’éviter la transmission du corps de la réponse si la ressource n’a pas changé depuis la dernière requête. Il s’agit d’un mécanisme fondamental de mise en cache HTTP défini dans la RFC 7232.

Pour les applications mobiles, Conditional GET est l’un des moyens les plus efficaces d’optimiser le trafic réseau. Un scénario typique : à l’ouverture de l’application, le client envoie une série de requêtes GET conditionnelles pour charger le fil d’actualité, le profil et les paramètres. Si les données n’ont pas changé, l’application reçoit 304 et utilise la copie locale. Cela prend des millisecondes au lieu de secondes et ne consomme pas de données mobiles.

Selon Google Web Fundamentals (2025), l’implémentation de requêtes GET conditionnelles dans une application mobile réduit le temps de chargement moyen de 40–60% pour les visites répétées et diminue l’utilisation du trafic de 70–90% pour les pages à mises à jour peu fréquentes. L’effet est particulièrement notable sur les connexions lentes (3G, Edge), où chaque octet compte.

Comment fonctionne une requête GET conditionnelle

Le processus comprend trois étapes. Première — le client envoie une requête GET normale, le serveur retourne la ressource avec les en-têtes de cache (ETag, Last-Modified). Deuxième — le client sauvegarde la ressource et ses validateurs localement. Troisième — lors d’une requête répétée, le client envoie un GET avec If-None-Match (pour ETag) et/ou If-Modified-Since (pour Last-Modified). Le serveur vérifie les validateurs et répond 304 si la ressource n’a pas changé, ou 200 avec de nouvelles données.

Le serveur utilise la priorité d’ETag sur Last-Modified lorsque les deux en-têtes sont présents. Cela est dû au fait qu’ETag fournit une validation plus précise — le hash du contenu change avec toute modification, tandis que Last-Modified a une résolution d’une seconde. Si l’ETag correspond, le serveur retourne immédiatement 304 sans vérifier Last-Modified.

Exemple d’un cycle complet de Conditional GET dans une séquence de requêtes :

// Étape 1 : Première requête — obtenir les données et ETag
GET /api/profile
Response: 200 OK
ETag: "33a64df551425fcc55e"
Body: { "name": "Alice" }

// Étape 2 : Répéter la requête — avec If-None-Match
GET /api/profile
If-None-Match: "33a64df551425fcc55e"
Response: 304 Not Modified
// Corps de réponse absent — utiliser la copie locale

Dans la deuxième requête, le serveur compare l’ETag de If-None-Match avec le hash actuel de la ressource. S’ils correspondent, il retourne 304 sans corps — le client continue d’utiliser les données en cache. C’est l’essence de Conditional GET : un trafic minimal avec une pertinence maximale des données.

Conditional GET vs GET normal

Une requête GET normale retourne toujours une réponse complète 200 OK avec un corps. Même si la ressource n’a pas changé, le serveur transmet toutes les données à nouveau. Cela est acceptable pour les petites ressources ou les requêtes peu fréquentes, mais pour les applications mobiles avec des centaines de requêtes à chaque lancement, cette approche entraîne une consommation excessive de trafic et de batterie.

Conditional GET ajoute une surcharge sous forme d’en-têtes (généralement 50–200 octets par requête) mais économise des kilo-octets et des méga-octets avec une réponse 304. Plus la ressource est grande, plus la requête conditionnelle est bénéfique. Pour les images, les listes de données et les documents JSON à partir de 10 Ko, Conditional GET est rentable dès la première requête répétée.

Caractéristiques comparatives des deux approches :

Exemples d’implémentation en Kotlin

Voyons une implémentation complète de Conditional GET en Kotlin avec OkHttp et Room pour le stockage d’ETag. Une application de liste de tâches charge les tâches depuis le serveur et utilise des requêtes conditionnelles pour minimiser le trafic. Les ETags sont stockés dans une base de données locale pour persister entre les sessions.

Dépôt avec Conditional GET en 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() // du cache 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 vérifie le code de réponse : 304 signifie aucun changement, et les données sont retournées depuis le cache local de Room. En 200, un nouvel ETag est sauvegardé et les tâches sont mises à jour dans la base de données locale. Ce motif est un standard pour les applications mobiles avec synchronisation via API REST.

Utilisation de Conditional GET dans le développement mobile

Conditional GET est largement utilisé dans les applications mobiles pour l’optimisation de la synchronisation des données. Principaux scénarios : chargement des flux d’actualités (Twitter, Instagram interrogent périodiquement l’API avec If-None-Match), mise à jour des profils utilisateur, chargement des listes de notifications et synchronisation des tâches. Dans chaque cas, l’application peut vérifier la pertinence des données sans les télécharger à nouveau.

Pour les applications offline-first, Conditional GET sert de première étape de la synchronisation. L’application envoie d’abord des requêtes GET conditionnelles pour toutes les ressources qui ont été modifiées localement depuis la dernière synchronisation. Les ressources avec 304 ne nécessitent pas de téléchargement. Ensuite, l’application envoie PUT/POST pour les modifications locales. Cette approche en deux phases garantit une consommation minimale de trafic.

En combinaison avec la Résolution de Conflits, Conditional GET permet une détection efficace des conflits. Si le client reçoit 200 avec de nouvelles données (la ressource a changé) mais a des modifications locales non envoyées — un conflit est enregistré. Le client peut soit appliquer LWW (les modifications locales sont perdues), soit lancer une Stratégie de Fusion pour fusionner les modifications locales et distantes. Selon Meta Engineering Blog (2025), l’implémentation de Conditional GET dans Messenger a réduit le trafic de synchronisation moyen de 73%.