Conditional GET: یہ کیا ہے، مشروط درخواست کا طریقہ کار

HTTP میں Conditional GET کیا ہے؟

Conditional GET ایک GET درخواست ہے جس میں ایک یا زیادہ مشروط ہیڈرز شامل ہوتے ہیں، جن کی بنیاد پر سرور فیصلہ کرتا ہے کہ مکمل جواب لوٹائے یا صرف 304 Not Modified حیثیت۔ بنیادی مقصد جوابی باڈی کی منتقلی سے بچنا ہے اگر وسائل آخری درخواست کے بعد سے تبدیل نہیں ہوا۔ یہ RFC 7232 میں بیان کردہ ایک بنیادی HTTP کیشنگ طریقہ کار ہے۔

موبائل ایپلیکیشنز کے لیے، Conditional GET نیٹ ورک ٹریفک کو بہتر بنانے کے سب سے مؤثر طریقوں میں سے ایک ہے۔ ایک عام منظرنامہ: ایپ کھولنے پر، کلائنٹ فیڈ، پروفائل اور سیٹنگز لوڈ کرنے کے لیے مشروط GET درخواستوں کا ایک سلسلہ بھیجتا ہے۔ اگر ڈیٹا تبدیل نہیں ہوا، ایپ 304 وصول کرتی ہے اور مقامی کاپی استعمال کرتی ہے۔ اس میں سیکنڈز کے بجائے ملی سیکنڈز لگتے ہیں اور موبائل ڈیٹا خرچ نہیں ہوتا۔

Google Web Fundamentals (2025) کے مطابق، موبائل ایپلیکیشن میں مشروط GET درخواستوں کو نافذ کرنے سے بار بار آنے والے دوروں کے لیے اوسط لوڈ وقت 40–60% کم ہوتا ہے اور کم تازہ کاری والے صفحات کے لیے ٹریفک کا استعمال 70–90% گھٹ جاتا ہے۔ اثر خاص طور پر سست کنیکشنز (3G، Edge) پر نمایاں ہے، جہاں ہر بائٹ اہم ہے۔

مشروط GET درخواست کیسے کام کرتی ہے

عمل تین مراحل پر مشتمل ہے۔ پہلا — کلائنٹ ایک عام GET درخواست بھیجتا ہے، سرور کیشنگ ہیڈرز (ETag، Last-Modified) کے ساتھ وسائل لوٹاتا ہے۔ دوسرا — کلائنٹ وسائل اور اس کے تصدیق کنندگان کو مقامی طور پر محفوظ کرتا ہے۔ تیسرا — دہرائی گئی درخواست پر، کلائنٹ If-None-Match (ETag کے لیے) اور/یا If-Modified-Since (Last-Modified کے لیے) کے ساتھ GET بھیجتا ہے۔ سرور تصدیق کنندگان کو چیک کرتا ہے اور اگر وسائل تبدیل نہیں ہوا تو 304، یا نئے ڈیٹا کے ساتھ 200 جواب دیتا ہے۔

سرور دونوں ہیڈرز موجود ہونے پر ETag کو Last-Modified پر ترجیح دیتا ہے۔ اس کی وجہ یہ ہے کہ ETag زیادہ درست تصدیق فراہم کرتا ہے — مواد کی ہیش کسی بھی تبدیلی کے ساتھ بدل جاتی ہے، جبکہ Last-Modified میں ایک سیکنڈ کی ریزولوشن ہے۔ اگر ETag مماثل ہے، سرور Last-Modified چیک کیے بغیر فوری 304 لوٹاتا ہے۔

درخواستوں کی ترتیب میں مکمل 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
// جوابی باڈی موجود نہیں — مقامی کاپی استعمال کریں

دوسری درخواست میں، سرور If-None-Match سے ETag کا موجودہ وسائل ہیش سے موازنہ کرتا ہے۔ اگر مماثل ہوں، تو یہ باڈی کے بغیر 304 لوٹاتا ہے — کلائنٹ کیشڈ ڈیٹا استعمال کرتا رہتا ہے۔ Conditional GET کا نچوڑ یہی ہے: کم سے کم ٹریفک کے ساتھ زیادہ سے زیادہ ڈیٹا کی تازگی۔

Conditional GET بمقابلہ عام GET

عام GET درخواست ہمیشہ باڈی کے ساتھ مکمل 200 OK جواب لوٹاتی ہے۔ چاہے وسائل تبدیل نہ ہوا ہو، سرور تمام ڈیٹا دوبارہ منتقل کرتا ہے۔ یہ چھوٹے وسائل یا کم درخواستوں کے لیے قابل قبول ہے، لیکن ہر لانچ پر سینکڑوں درخواستوں والی موبائل ایپلیکیشنز کے لیے، یہ طریقہ ضرورت سے زیادہ ٹریفک اور بیٹری خرچ کا باعث بنتا ہے۔

Conditional GET ہیڈرز کی شکل میں اوور ہیڈ شامل کرتا ہے (عام طور پر 50–200 بائٹس فی درخواست) لیکن 304 جواب کے ساتھ کلو بائٹس اور میگا بائٹس بچاتا ہے۔ وسائل جتنا بڑا ہوگا، مشروط درخواست اتنی ہی فائدہ مند ہوگی۔ تصاویر، ڈیٹا کی فہرستوں اور 10 KB اور اس سے اوپر کی JSON دستاویزات کے لیے، Conditional GET پہلی دہرائی گئی درخواست سے ہی فائدہ مند ہو جاتا ہے۔

دو طریقوں کی تقابلی خصوصیات:

Kotlin میں نفاذ کی مثالیں

آئیے ایک مکمل نفاذ دیکھتے ہیں — ETag ذخیرہ کرنے کے لیے OkHttp اور Room کا استعمال کرتے ہوئے Kotlin میں Conditional GET کا نفاذ۔ ایک ٹاسک لسٹ ایپلیکیشن سرور سے ٹاسک لوڈ کرتی ہے اور ٹریفک کم سے کم کرنے کے لیے مشروط درخواستیں استعمال کرتی ہے۔ ETags سیشنز کے درمیان برقرار رکھنے کے لیے لوکل ڈیٹا بیس میں محفوظ کیے جاتے ہیں۔

Kotlin میں Conditional GET کے ساتھ ذخیرہ:

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 وقتاً فوقتاً If-None-Match کے ساتھ API سے استفسار کرتے ہیں)، صارف پروفائلز اپ ڈیٹ کرنا، نوٹیفکیشن فہرستیں لوڈ کرنا اور ٹاسک سنکرونائز کرنا۔ ہر صورت میں، ایپ ڈیٹا کو دوبارہ ڈاؤن لوڈ کیے بغیر اس کی تازگی جانچ سکتی ہے۔

آف لائن پہلی ایپلیکیشنز کے لیے، Conditional GET ہم آہنگی کے پہلے مرحلے کے طور پر کام کرتا ہے۔ ایپ پہلے ان تمام وسائل کے لیے مشروط GET درخواستیں بھیجتی ہے جو آخری ہم آہنگی کے بعد مقامی طور پر تبدیل ہوئے ہیں۔ 304 والے وسائل کو ڈاؤن لوڈ کرنے کی ضرورت نہیں۔ اس کے بعد، ایپ مقامی تبدیلیوں کے لیے PUT/POST بھیجتی ہے۔ یہ دو مرحلہ طریقہ کم سے کم ٹریفک خرچ کو یقینی بناتا ہے۔

تنازعہ حل کے ساتھ مل کر، Conditional GET موثر تنازعہ کا پتہ لگانے کی اجازت دیتا ہے۔ اگر کلائنٹ کو نئے ڈیٹا کے ساتھ 200 ملتا ہے (وسائل تبدیل ہوا) لیکن اس کے پاس غیر بھیجی گئی مقامی تبدیلیاں ہیں — ایک تنازعہ ریکارڈ کیا جاتا ہے۔ کلائنٹ LWW لاگو کر سکتا ہے (مقامی تبدیلیاں ضائع ہو جاتی ہیں) یا مقامی اور دور دراز تبدیلیوں کو ضم کرنے کے لیے انضمام کی حکمت عملی شروع کر سکتا ہے۔ Meta Engineering Blog (2025) کے مطابق، Messenger میں Conditional GET کے نفاذ نے اوسط ہم آہنگی ٹریفک کو 73% کم کیا۔