Conditional GET: τι είναι, μηχανισμός υπό όρους αιτήματος

Τι είναι το Conditional GET στο HTTP;

Conditional GET — είναι ένα αίτημα GET που περιέχει μία ή περισσότερες κεφαλίδες υπό όρους, βάσει των οποίων ο διακομιστής αποφασίζει εάν θα επιστρέψει πλήρη απόκριση ή μόνο την κατάσταση 304 Not Modified. Ο κύριος στόχος είναι η αποφυγή μετάδοσης του σώματος απόκρισης, εάν ο πόρος δεν έχει αλλάξει από το τελευταίο αίτημα. Αυτός είναι ένας θεμελιώδης μηχανισμός προσωρινής αποθήκευσης HTTP, που ορίζεται στην προδιαγραφή RFC 7232.

Για εφαρμογές για κινητά, το Conditional GET είναι ένας από τους πιο αποτελεσματικούς τρόπους βελτιστοποίησης της κυκλοφορίας δικτύου. Τυπικό σενάριο: κατά το άνοιγμα της εφαρμογής, ο πελάτης στέλνει μια σειρά αιτημάτων GET υπό όρους για φόρτωση της ροής, του προφίλ και των ρυθμίσεων. Εάν τα δεδομένα δεν έχουν αλλάξει, η εφαρμογή λαμβάνει 304 και χρησιμοποιεί το τοπικό αντίγραφο. Αυτό διαρκεί χιλιοστά του δευτερολέπτου αντί για δευτερόλεπτα και δεν καταναλώνει κινητή κίνηση.

Σύμφωνα με το Google Web Fundamentals (2025), η εφαρμογή αιτημάτων GET υπό όρους σε μια εφαρμογή για κινητά μειώνει τον μέσο χρόνο φόρτωσης κατά 40–60% για επαναλαμβανόμενες επισκέψεις και μειώνει την κατανάλωση κίνησης κατά 70–90% για σελίδες με σπάνιες ενημερώσεις. Το αποτέλεσμα είναι ιδιαίτερα αισθητό σε αργές συνδέσεις (3G, Edge), όπου κάθε byte μετράει.

Πώς λειτουργεί το αίτημα GET υπό όρους

Η διαδικασία αποτελείται από τρία βήματα. Πρώτο — ο πελάτης στέλνει ένα κανονικό αίτημα GET, ο διακομιστής επιστρέφει τον πόρο μαζί με τις κεφαλίδες προσωρινής αποθήκευσης (ETag, Last-Modified). Δεύτερο — ο πελάτης αποθηκεύει τον πόρο και τους επικυρωτές του τοπικά. Τρίτο — σε επαναλαμβανόμενο αίτημα, ο πελάτης στέλνει GET με If-None-Match (για ETag) ή/και If-Modified-Since (για Last-Modified). Ο διακομιστής ελέγχει τους επικυρωτές και απαντά 304 εάν ο πόρος δεν έχει αλλάξει, ή 200 με νέα δεδομένα.

Ο διακομιστής χρησιμοποιεί προτεραιότητα του ETag έναντι του Last-Modified όταν υπάρχουν και οι δύο κεφαλίδες. Αυτό συμβαίνει επειδή το ETag παρέχει ακριβέστερη επικύρωση — το hash περιεχομένου αλλάζει με οποιαδήποτε αλλαγή, ενώ το Last-Modified έχει ανάλυση ενός δευτερολέπτου. Εάν το ETag ταιριάζει, ο διακομιστής επιστρέφει αμέσως 304, χωρίς να ελέγξει το Last-Modified.

Παράδειγμα πλήρους κύκλου Conditional GET στην ακολουθία αιτημάτων:

// Βήμα 1: Πρώτο αίτημα — λήψη δεδομένων και ETag
GET /api/profile
Response: 200 OK
ETag: "33a64df551425fcc55e"
Body: { "name": "Alice" }

// Βήμα 2: Επανάληψη αιτήματος — με If-None-Match
GET /api/profile
If-None-Match: "33a64df551425fcc55e"
Response: 304 Not Modified
// Το σώμα απόκρισης απουσιάζει — χρησιμοποιήστε το τοπικό αντίγραφο

Στο δεύτερο αίτημα, ο διακομιστής συγκρίνει το ETag από το If-None-Match με το τρέχον hash του πόρου. Σε περίπτωση αντιστοιχίας, επιστρέφεται 304 χωρίς σώμα — ο πελάτης συνεχίζει να χρησιμοποιεί τα δεδομένα από την προσωρινή μνήμη. Αυτή είναι η ουσία του Conditional GET: ελάχιστη κίνηση με μέγιστη επικαιρότητα δεδομένων.

Conditional GET εναντίον κανονικού GET

Το κανονικό αίτημα GET επιστρέφει πάντα πλήρη απόκριση 200 OK με σώμα. Ακόμα κι αν ο πόρος δεν έχει αλλάξει, ο διακομιστής μεταδίδει ξανά όλα τα δεδομένα. Αυτό είναι αποδεκτό για μικρούς πόρους ή σπάνια αιτήματα, αλλά για εφαρμογές για κινητά με εκατοντάδες αιτήματα σε κάθε εκκίνηση, μια τέτοια προσέγγιση οδηγεί σε υπερβολική κατανάλωση κίνησης και μπαταρίας.

Conditional GET προσθέτει επιβάρυνση με τη μορφή κεφαλίδων (συνήθως 50–200 byte ανά αίτημα), αλλά εξοικονομεί kilobyte και megabyte στην απόκριση 304. Όσο μεγαλύτερος είναι ο πόρος, τόσο πιο συμφέρουσα είναι η αίτηση υπό όρους. Για εικόνες, λίστες δεδομένων και έγγραφα JSON από 10 KB και άνω, το Conditional GET αποδίδει από το πρώτο επαναλαμβανόμενο αίτημα.

Σύγκριση των δύο προσεγγίσεων:

Παραδείγματα υλοποίησης σε Kotlin

Ας εξετάσουμε μια πλήρη υλοποίηση του Conditional GET σε Kotlin χρησιμοποιώντας OkHttp και Room για αποθήκευση ETag. Μια εφαρμογή λίστας εργασιών φορτώνει εργασίες από τον διακομιστή και χρησιμοποιεί αιτήματα υπό όρους για ελαχιστοποίηση της κίνησης. Τα ETag αποθηκεύονται στην τοπική βάση δεδομένων για διατήρηση μεταξύ των συνεδριών.

Αποθετήριο με Conditional GET σε 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() // από την τοπική προσωρινή μνήμη
            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 ελέγχει τον κωδικό απόκρισης: το 304 σημαίνει καμία αλλαγή και τα δεδομένα επιστρέφονται από την τοπική προσωρινή μνήμη Room. Στο 200, το νέο ETag αποθηκεύεται και οι εργασίες ενημερώνονται στην τοπική βάση δεδομένων. Αυτό το μοτίβο είναι το πρότυπο για εφαρμογές για κινητά που συγχρονίζονται μέσω REST API.

Εφαρμογή του Conditional GET στην ανάπτυξη εφαρμογών για κινητά

Το Conditional GET χρησιμοποιείται ευρέως σε εφαρμογές για κινητά για βελτιστοποίηση του συγχρονισμού δεδομένων. Βασικά σενάρια: φόρτωση ροής ειδήσεων (Twitter, Instagram περιοδικά ρωτούν το API με If-None-Match), ενημέρωση προφίλ χρήστη, φόρτωση λίστας ειδοποιήσεων και συγχρονισμός εργασιών. Σε κάθε περίπτωση, η εφαρμογή μπορεί να ελέγξει την επικαιρότητα των δεδομένων χωρίς να τα φορτώσει ξανά.

Για εφαρμογές offline-first, το Conditional GET χρησιμεύει ως το πρώτο στάδιο συγχρονισμού. Η εφαρμογή στέλνει πρώτα αιτήματα GET υπό όρους για όλους τους πόρους που έχουν τροποποιηθεί τοπικά από τον τελευταίο συγχρονισμό. Οι πόροι με 304 δεν απαιτούν φόρτωση. Στη συνέχεια, η εφαρμογή στέλνει PUT/POST για τοπικές αλλαγές. Μια τέτοια προσέγγιση δύο φάσεων εξασφαλίζει ελάχιστη κατανάλωση κίνησης.

Σε συνδυασμό με το Conflict Resolution, το Conditional GET επιτρέπει τον αποτελεσματικό εντοπισμό διενέξεων. Εάν ο πελάτης έλαβε 200 με νέα δεδομένα (ο πόρος άλλαξε), αλλά ο πελάτης έχει μη σταλείσες τοπικές αλλαγές — καταγράφεται διένεξη. Ο πελάτης μπορεί να εφαρμόσει LWW (οι τοπικές αλλαγές χάνονται) ή να εκκινήσει μια Στρατηγική Συγχώνευσης για συνδυασμό τοπικών και απομακρυσμένων αλλαγών. Σύμφωνα με το Meta Engineering Blog (2025), η εφαρμογή του Conditional GET στο Messenger μείωσε τη μέση κατανάλωση κίνησης συγχρονισμού κατά 73%.