Conditional GET: nədir, şərti sorğu mexanizmi

HTTP-də Conditional GET nədir?

Conditional GET — bir və ya bir neçə şərti başlıq ehtiva edən GET sorğusudur. Bu başlıqlar əsasında server tam cavab qaytarmaq və ya yalnız 304 Not Modified statusu göndərmək qərarı verir. Əsas məqsəd — resurs son sorğudan bəri dəyişməyibsə, cavab gövdəsinin ötürülməsindən qaçmaqdır. Bu, RFC 7232 spesifikasiyasında müəyyən edilmiş HTTP keşləməsinin fundamental mexanizmidir.

Mobil tətbiqlər üçün Conditional GET şəbəkə trafikinin optimallaşdırılmasının ən effektiv yollarından biridir. Tipik ssenari: tətbiq açıldıqda müştəri lent, profil və parametrləri yükləmək üçün bir sıra şərti GET sorğuları göndərir. Məlumat dəyişməyibsə, tətbiq 304 alır və yerli surətdən istifadə edir. Bu, saniyələr əvəzinə millisaniyələr çəkir və mobil trafik sərf etmir.

Google Web Fundamentals (2025) məlumatına görə, mobil tətbiqdə şərti GET sorğularının tətbiqi təkrar ziyarətlər üçün orta yükləmə müddətini 40–60% azaldır və nadir yenilənən səhifələr üçün trafik sərfini 70–90% azaldır. Effekt xüsusilə yavaş bağlantılarda (3G, Edge) nəzərə çarpır, burada hər bayt əhəmiyyətlidir.

Şərti GET sorğusu necə işləyir

Proses üç addımdan ibarətdir. Birinci — müştəri adi GET sorğusu göndərir, server resursu keşləmə başlıqları (ETag, Last-Modified) ilə birlikdə qaytarır. İkinci — müştəri resursu və onun validatorlarını lokal olaraq saxlayır. Üçüncü — təkrar sorğuda müştəri If-None-Match (ETag üçün) və/və ya If-Modified-Since (Last-Modified üçün) ilə GET göndərir. Server validatorları yoxlayır və resurs dəyişməyibsə 304, yeni məlumat varsa 200 cavabı qaytarır.

Server hər iki başlıq mövcud olduqda ETag-ə Last-Modified-dən üstünlük verir. Bu, ETag-in daha dəqiq validasiya təmin etməsi ilə bağlıdır — məzmun heşi istənilən dəyişiklikdə dəyişir, halbuki Last-Modified bir saniyə dəqiqliyə malikdir. ETag uyğun gələrsə, server dərhal 304 qaytarır, Last-Modified-i yoxlamır.

Sorğu ardıcıllığında Conditional GET-in tam dövrü nümunəsi:

// Addım 1: İlk sorğu — məlumatları və ETag-i əldə edin
GET /api/profile
Response: 200 OK
ETag: "33a64df551425fcc55e"
Body: { "name": "Alice" }

// Addım 2: Sorğunu təkrarlayın — If-None-Match ilə
GET /api/profile
If-None-Match: "33a64df551425fcc55e"
Response: 304 Not Modified
// Cavab gövdəsi yoxdur — yerli surətdən istifadə edin

İkinci sorğuda server If-None-Match-dəki ETag-i resursun cari heşi ilə müqayisə edir. Uyğunluq halında 304 cavabsız qaytarılır — müştəri keşlənmiş məlumatlardan istifadəyə davam edir. Conditional GET-in mahiyyəti budur: maksimum məlumat aktuallığı ilə minimum trafik.

Conditional GET və adi GET

Adi GET sorğusu həmişə gövdə ilə tam 200 OK cavabı qaytarır. Resurs dəyişməsə belə, server bütün məlumatları yenidən ötürür. Bu, kiçik resurslar və ya nadir sorğular üçün məqbuldur, lakin hər açılışda yüzlərlə sorğu göndərən mobil tətbiqlər üçün bu yanaşma həddindən artıq trafik və batareya sərfinə səbəb olur.

Conditional GET başlıqlar şəklində əlavə yük əlavə edir (adətən sorğuya 50–200 bayt), lakin 304 cavabında kilobayt və meqabaytlara qənaət edir. Resurs nə qədər böyükdürsə, şərti sorğu bir o qədər sərfəlidir. 10 KB-dan böyük şəkillər, məlumat siyahıları və JSON sənədləri üçün Conditional GET ilk təkrar sorğuda özünü doğruldur.

İki yanaşmanın müqayisəsi:

Kotlin-də tətbiq nümunələri

Tam tətbiqi nəzərdən keçirək — OkHttp və ETag saxlamaq üçün Room istifadə edərək Kotlin-də Conditional GET. Tapşırıq siyahısı tətbiqi serverdən tapşırıqları yükləyir və trafiki minimuma endirmək üçün şərti sorğulardan istifadə edir. ETag-lər sessiyalar arasında qorunmaq üçün lokal verilənlər bazasında saxlanılır.

Kotlin-də Conditional GET ilə depozitari:

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() // lokal keşdən
            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 cavab kodunu yoxlayır: 304 dəyişiklik olmadığını bildirir və məlumatlar Room-un lokal keşindən qaytarılır. 200-də yeni ETag saxlanılır və tapşırıqlar lokal bazada yenilənir. Bu nümunə REST API vasitəsilə sinxronizasiya edən mobil tətbiqlər üçün standartdır.

Conditional GET-in mobil inkişafda tətbiqi

Conditional GET geniş istifadə olunur mobil tətbiqlərdə məlumat sinxronizasiyasını optimallaşdırmaq üçün. Əsas ssenarilər: xəbər lentinin yüklənməsi (Twitter, Instagram dövri olaraq API-ni If-None-Match ilə sorğulayır), istifadəçi profilinin yenilənməsi, bildiriş siyahısının yüklənməsi və tapşırıqların sinxronizasiyası. Hər bir halda tətbiq məlumatları yenidən yükləmədən aktuallığını yoxlaya bilər.

Offline-first tətbiqləri üçün Conditional GET sinxronizasiyanın ilk mərhələsi kimi xidmət edir. Tətbiq əvvəlcə son sinxronizasiyadan bəri lokal olaraq dəyişdirilmiş bütün resurslar üçün şərti GET sorğuları göndərir. 304 olan resurslar yükləmə tələb etmir. Bundan sonra tətbiq lokal dəyişikliklər üçün PUT/POST göndərir. Belə iki fazalı yanaşma minimal trafik sərfini təmin edir.

Conflict Resolution ilə birlikdə Conditional GET münaqişələri effektiv aşkarlamağa imkan verir. Əgər müştəri yeni məlumatlarla 200 alıbsa (resurs dəyişib), lakin müştərinin göndərilməmiş lokal dəyişiklikləri varsa — münaqişə qeydə alınır. Müştəri LWW tətbiq edə bilər (lokal dəyişikliklər itir) və ya lokal və uzaq dəyişiklikləri birləşdirmək üçün Merge Strategy işə sala bilər. Meta Engineering Blog (2025) məlumatına görə, Messenger-də Conditional GET-in tətbiqi sinxronizasiya üzrə orta trafik sərfini 73% azaldıb.