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 में कार्यान्वयन उदाहरण

आइए एक पूर्ण कार्यान्वयन देखें OkHttp और Room का उपयोग करके Kotlin में Conditional GET का, ETag भंडारण के लिए। एक कार्य सूची एप्लिकेशन सर्वर से कार्य लोड करता है और ट्रैफ़िक को कम करने के लिए सशर्त अनुरोधों का उपयोग करता है। 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% कम हो गया।