Conditional GET: nima, shartli so'rov mexanizmi

HTTP da Conditional GET nima?

Conditional GET — bir yoki bir nechta shartli sarlavhalarni o'z ichiga olgan GET so'rovi bo'lib, ular asosida server to'liq javobni yoki faqat 304 Not Modified statusini qaytarishga qaror qiladi. Asosiy maqsad — resurs oxirgi so'rovdan beri o'zgarmagan bo'lsa, javob tanasini uzatishdan qochishdir. Bu RFC 7232 spetsifikatsiyasida belgilangan HTTP keshlashning fundamental mexanizmidir.

Mobil ilovalar uchun Conditional GET tarmoq trafigini optimallashtirishning eng samarali usullaridan biridir. Odatdagi stsenariy: ilova ochilganda, mijoz lentani, profilni va sozlamalarni yuklash uchun bir qator shartli GET so'rovlarini yuboradi. Agar ma'lumotlar o'zgarmagan bo'lsa, ilova 304 oladi va mahalliy nusxadan foydalanadi. Bu soniyalar o'rniga millisoniyalar davom etadi va mobil trafikni sarflamaydi.

Google Web Fundamentals (2025) ma'lumotlariga ko'ra, mobil ilovada shartli GET so'rovlarini joriy etish takroriy tashriflar uchun o'rtacha yuklash vaqtini 40–60% ga qisqartiradi va kam yangilanadigan sahifalar uchun trafik sarfini 70–90% ga kamaytiradi. Effekt ayniqsa sekin ulanishlarda (3G, Edge) sezilarli bo'ladi, bunda har bir bayt muhim ahamiyatga ega.

Shartli GET so'rovi qanday ishlaydi

Jarayon uch bosqichdan iborat. Birinchi — mijoz oddiy GET so'rovini yuboradi, server resursni keshlash sarlavhalari (ETag, Last-Modified) bilan birga qaytaradi. Ikkinchi — mijoz resursni va uning validatorlarini mahalliy saqlaydi. Uchinchi — takroriy so'rovda mijoz If-None-Match (ETag uchun) va/yoki If-Modified-Since (Last-Modified uchun) bilan GET yuboradi. Server validatorlarni tekshiradi va agar resurs o'zgarmagan bo'lsa 304, aks holda 200 yangi ma'lumotlar bilan javob beradi.

Server ikkala sarlavha mavjud bo'lganda ETag ning Last-Modified dan ustuvorligini qo'llaydi. Buning sababi, ETag aniqroq validatsiyani ta'minlaydi — mazmun xeshi har qanday o'zgarishda o'zgaradi, holda Last-Modified bir soniya aniqligiga ega. Agar ETag mos kelsa, server darhol 304 qaytaradi, Last-Modified ni tekshirmaydi.

So'rovlar ketma-ketligida Conditional GET ning to'liq sikli namunasi:

// 1-qadam: Birinchi so'rov — ma'lumotlar va ETag ni oling
GET /api/profile
Response: 200 OK
ETag: "33a64df551425fcc55e"
Body: { "name": "Alice" }

// 2-qadam: So'rovni takrorlang — If-None-Match bilan
GET /api/profile
If-None-Match: "33a64df551425fcc55e"
Response: 304 Not Modified
// Javob tanasi yo'q — mahalliy nusxadan foydalaning

Ikkinchi so'rovda server If-None-Match dagi ETag ni resursning joriy xeshi bilan solishtiradi. Mos kelganda, 304 tanasiz qaytariladi — mijoz keshlangan ma'lumotlardan foydalanishni davom ettiradi. Bu Conditional GET ning mohiyati: maksimal ma'lumot dolzarbligi bilan minimal trafik.

Conditional GET oddiy GET ga qarshi

Oddiy GET so'rovi har doim tana bilan to'liq 200 OK javobini qaytaradi. Resurs o'zgarmagan bo'lsa ham, server barcha ma'lumotlarni qaytadan uzatadi. Bu kichik resurslar yoki kam so'rovlar uchun maqbul, ammo har ishga tushirishda yuzlab so'rovlar yuboradigan mobil ilovalar uchun bunday yondashuv ortiqcha trafik va batareya sarfiga olib keladi.

Conditional GET sarlavhalar ko'rinishida qo'shimcha yuk qo'shadi (odatda so'rov uchun 50–200 bayt), ammo 304 javobida kilobayt va megabaytlarni tejaydi. Resurs qanchalik katta bo'lsa, shartli so'rov shunchalik foydali bo'ladi. 10 KB dan katta tasvirlar, ma'lumotlar ro'yxatlari va JSON hujjatlari uchun Conditional GET birinchi takroriy so'rovda o'zini oqlaydi.

Ikki yondashuvning taqqoslashi:

Kotlin da amalga oshirish misollari

To'liq amalga oshirishni ko'rib chiqamiz — OkHttp va ETag saqlash uchun Room dan foydalangan holda Kotlin da Conditional GET. Vazifalar ro'yxati ilovasi serverdan vazifalarni yuklaydi va trafikni minimallashtirish uchun shartli so'rovlardan foydalanadi. ETag lar sessiyalar orasida saqlanish uchun mahalliy ma'lumotlar bazasida saqlanadi.

Kotlin da Conditional GET bilan repozitoriy:

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() // mahalliy keshdan
            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 javob kodini tekshiradi: 304 o'zgarish yo'qligini bildiradi va ma'lumotlar Room ning mahalliy keshidan qaytariladi. 200 da yangi ETag saqlanadi va vazifalar mahalliy bazada yangilanadi. Ushbu naqsh REST API orqali sinxronlanadigan mobil ilovalar uchun standartdir.

Conditional GET ni mobil ishlanmada qo'llash

Conditional GET keng qo'llaniladi mobil ilovalarda ma'lumotlar sinxronizatsiyasini optimallashtirish uchun. Asosiy stsenariylar: yangiliklar lentasini yuklash (Twitter, Instagram davriy ravishda API ni If-None-Match bilan so'raydi), foydalanuvchi profilini yangilash, bildirishnomalar ro'yxatini yuklash va vazifalarni sinxronlashtirish. Har bir holatda ilova ma'lumotlarni qayta yuklamasdan ularning dolzarbligini tekshirishi mumkin.

Offline-first ilovalari uchun Conditional GET sinxronizatsiyaning birinchi bosqichi sifatida xizmat qiladi. Ilova avval oxirgi sinxronizatsiyadan beri mahalliy o'zgartirilgan barcha resurslar uchun shartli GET so'rovlarini yuboradi. 304 bo'lgan resurslar yuklashni talab qilmaydi. Shundan so'ng ilova mahalliy o'zgarishlar uchun PUT/POST yuboradi. Bunday ikki fazali yondashuv minimal trafik sarfini ta'minlaydi.

Conflict Resolution bilan birgalikda Conditional GET nizolarni samarali aniqlash imkonini beradi. Agar mijoz yangi ma'lumotlar bilan 200 olgan bo'lsa (resurs o'zgargan), lekin mijozda yuborilmagan mahalliy o'zgarishlar bo'lsa — nizo qayd etiladi. Mijoz LWW ni qo'llashi mumkin (mahalliy o'zgarishlar yo'qoladi) yoki mahalliy va uzoq o'zgarishlarni birlashtirish uchun Merge Strategy ni ishga tushirishi mumkin. Meta Engineering Blog (2025) ma'lumotlariga ko'ra, Messenger da Conditional GET ni joriy etish sinxronizatsiya bo'yicha o'rtacha trafik sarfini 73% ga kamaytirdi.