एप्लिकेशन में ETag — यह क्या है, उद्देश्य और सिद्धांत
ETag एक HTTP रिस्पॉन्स हेडर है जिसमें संसाधन संस्करण का एक अद्वितीय पहचानकर्ता होता है। सर्वर ETag को कंटेंट हैश या वर्ज़न नंबर के रूप में उत्पन्न करता है और डेटा के साथ क्लाइंट को लौटाता है। बाद के अनुरोधों में, क्लाइंट इस पहचानकर्ता को If-None-Match हेडर में भेजता है, जिससे सर्वर यह जांच सकता है कि संसाधन बदला है या नहीं। MDN Web Docs, 2025 के अनुसार, ETag HTTP में सशर्त GET अनुरोध तंत्र का आधार है। ETag के साथ सशर्त अनुरोध मोबाइल एप्लिकेशन सिंक्रनाइज़ेशन के दौरान स्थानांतरित डेटा की मात्रा को 90% तक कम करते हैं।
मुख्य बिंदु
- ETag एक HTTP हेडर है जिसमें संसाधन संस्करण का अद्वितीय पहचानकर्ता होता है, आमतौर पर इसकी सामग्री का हैश।
- If-None-Match — क्लाइंट संग्रहीत ETag भेजता है, सर्वर 304 Not Modified लौटाता है यदि संसाधन नहीं बदला है।
- ट्रैफ़िक बचत — ETag के साथ सशर्त अनुरोध मोबाइल एप्लिकेशन सिंक्रनाइज़ेशन के दौरान डेटा वॉल्यूम कम करते हैं क्योंकि प्रतिक्रिया निकाय प्रेषित नहीं होता है।
- मजबूत और कमजोर ETag — मजबूत बाइट-दर-बाइट सामग्री में अंतर करते हैं, कमजोर संसाधन की शब्दार्थ समतुल्यता की अनुमति देते हैं।
- उपयोग — ETag का उपयोग REST API में डेटा सिंक्रनाइज़ेशन, कैशिंग और संपादन विरोधों को रोकने के लिए किया जाता है।
HTTP और मोबाइल एप्लिकेशन में ETag क्या है?
ETag (Entity Tag) सशर्त हेडर परिवार से एक HTTP हेडर है जो कैश्ड संसाधनों को मान्य करता है। सर्वर ETag को हैश (MD5, SHA-256) या संसाधन संस्करण संख्या के रूप में गणना करता है और GET अनुरोध के जवाब में लौटाता है। क्लाइंट ETag को डेटा के साथ संग्रहीत करता है और बाद के अनुरोधों में इसे If-None-Match हेडर में भेजता है। यदि संसाधन सामग्री नहीं बदली है, तो सर्वर प्रतिक्रिया निकाय के बिना 304 Not Modified स्थिति के साथ प्रतिक्रिया करता है।
मोबाइल एप्लिकेशन के लिए, ETag अत्यंत महत्वपूर्ण है क्योंकि यह डाउनलोड किए गए डेटा की मात्रा को कम करता है। प्रत्येक लॉन्च या सिंक्रनाइज़ेशन पर, एप्लिकेशन If-None-Match अनुरोध के साथ संसाधनों की ताज़गी की जाँच करता है — पूर्ण डेटा लोड करने के बजाय, इसे 304 प्राप्त होता है और स्थानीय प्रतिलिपि का उपयोग करता है। Google Chrome Team (2024) के अनुसार, मोबाइल API में ETag का उपयोग सूचियों के लिए औसत प्रतिक्रिया आकार को 87% और व्यक्तिगत वस्तुओं के लिए 94% तक कम करता है।
ETag सर्वर-साइड उत्पन्न होता है और नियतात्मक (समान सामग्री के लिए समान, साझा कैश के लिए उपयोगी) या प्रति प्रतिक्रिया अद्वितीय (सख्त मान्यता के लिए) हो सकता है। मोबाइल सिंक्रनाइज़ेशन के लिए डिज़ाइन किए गए REST API में, सबसे आम संयोजन सामग्री हैश और डेटाबेस में रिकॉर्ड संस्करण संख्या है।
ETag के प्रकार: मजबूत और कमजोर पहचानकर्ता
मजबूत ETag (strong ETag) ऐसे पहचानकर्ता हैं जो सामग्री में किसी भी बदलाव पर बदलते हैं, जिसमें मामूली बदलाव (रिक्त स्थान, स्वरूपण) शामिल हैं। प्रारूप: “abc123def” (डबल कोट्स में, बिना उपसर्ग के)। मजबूत ETag गारंटी देते हैं कि संसाधन बाइट-दर-बाइट नहीं बदला है। वे रेंज अनुरोधों (Range requests) और आंशिक डाउनलोड की अखंडता की जाँच के लिए अनिवार्य हैं।
कमजोर ETag (weak ETag) W/ उपसर्ग वाले पहचानकर्ता हैं, उदाहरण के लिए W/“abc123def”। वे अनुमति देते हैं कि संसाधन शब्दार्थ रूप से समतुल्य है भले ही बाइट प्रतिनिधित्व भिन्न हो। कमजोर ETag उन सर्वरों के लिए उपयोगी हैं जो अलग-अलग रिक्त स्थान या स्वरूपण लेकिन समान अर्थ के साथ गतिशील रूप से प्रतिक्रिया उत्पन्न करते हैं। हालांकि, कमजोर ETag रेंज अनुरोधों का समर्थन नहीं करते हैं।
ETag प्रकारों की तुलना:
| विशेषता | मजबूत ETag | कमजोर ETag |
|---|---|---|
| प्रारूप | “hash” | W/“hash” |
| संवेदनशीलता | बाइट-दर-बाइट | शब्दार्थ |
| रेंज अनुरोध | समर्थित | समर्थित नहीं |
| CDN कैशिंग | आदर्श | सीमित |
| सिंक्रनाइज़ेशन | उच्च सटीकता | टकराव की अनुमति |
ETag बनाम Last-Modified: क्या चुनें
Last-Modified एक HTTP हेडर है जो अंतिम संसाधन संशोधन की तिथि और समय को इंगित करता है। क्लाइंट इसे If-Modified-Since हेडर में वापस भेजता है। Last-Modified को लागू करना सरल है (सर्वर को केवल तिथि चाहिए), लेकिन इसमें मूलभूत सीमाएँ हैं: एक सेकंड का रिज़ॉल्यूशन (एक ही सेकंड में दो बदलाव अप्रभेद्य हैं) और यह निर्धारित करने में असमर्थता कि समान टाइमस्टैम्प होने पर सामग्री बदली है या नहीं (उदाहरण के लिए, बैकअप पुनर्स्थापना के बाद)।
ETag इन समस्याओं को हल करता है: सामग्री हैश समय की परवाह किए बिना किसी भी संशोधन पर बदलता है। इसलिए, आधुनिक REST API दोनों हेडर के संयोजन का उपयोग करते हैं: सटीक मान्यता के लिए ETag और अनुमानित CDN फ़िल्टरिंग के लिए Last-Modified। Apache HTTP Server और Nginx डिफ़ॉल्ट रूप से स्थिर फ़ाइलों के लिए दोनों हेडर उत्पन्न करते हैं।
सिंक्रनाइज़ेशन वाले मोबाइल एप्लिकेशन के लिए, ETag अधिक महत्वपूर्ण है क्योंकि यह संपादन विरोधों का पता लगाने की अनुमति देता है। यदि कोई क्लाइंट If-Match: “etag” के साथ PUT अनुरोध भेजता है, तो सर्वर अनुरोध को अस्वीकार कर देता है यदि संसाधन किसी अन्य क्लाइंट द्वारा संशोधित किया गया था (आशावादी लॉकिंग)। Last-Modified सेकंड-स्तरीय सटीकता के कारण ऐसी विश्वसनीयता की गारंटी नहीं दे सकता।
Kotlin में ETag के साथ काम करने के उदाहरण
आइए एक क्लाइंट-साइड कार्यान्वयन देखें Retrofit और OkHttp के साथ Kotlin का उपयोग करके मोबाइल एप्लिकेशन में ETag का। प्रत्येक GET अनुरोध पर, क्लाइंट प्रतिक्रिया से ETag सहेजता है, और अगले अनुरोध पर इसे If-None-Match हेडर में भेजता है। यदि सर्वर 304 लौटाता है, तो डेटा पुनः डाउनलोड नहीं किया जाता है।
ETag कैशिंग के साथ OkHttp क्लाइंट सेट करना:
kotlin
class EtagClient {
private val etagCache =
mutableMapOf<String, String>()
private val client = OkHttpClient.Builder().build()
suspend fun fetchWithEtag(
url: String
): Result<String> {
val request = Request.Builder()
.url(url)
.header("If-None-Match",
etagCache[url] ?: "")
.build()
val response = client.newCall(request).await()
return when (response.code) {
304 -> Result.success(
"not_modified")
200 -> {
response.header("ETag")?.let {
etagCache[url] = it
}
Result.success(response.body?.string()
?: "")
}
else -> Result.failure(
Exception("HTTP ${response.code}"))
}
}
}क्लाइंट सफल 200 प्रतिक्रिया के बाद ETag सहेजता है और अगले अनुरोध पर इसे If-None-Match हेडर में भेजता है। 304 प्रतिक्रिया पर, क्लाइंट जानता है कि स्थानीय संस्करण वर्तमान है और पुनः डाउनलोड करने पर ट्रैफ़िक बर्बाद नहीं करता है। यह पैटर्न बार-बार अनुरोधित संसाधनों के लिए मोबाइल एप्लिकेशन के नेटवर्क खर्च को 80–90% तक कम करता है।
मोबाइल एप्लिकेशन सिंक्रनाइज़ेशन में ETag की भूमिका
ETag एक महत्वपूर्ण तंत्र है REST API के साथ मोबाइल एप्लिकेशन सिंक्रनाइज़ेशन को अनुकूलित करने के लिए। मानक सिंक योजना में, क्लाइंट पहले ETag मान्यता के साथ संसाधनों की सूची का अनुरोध करता है — यदि कोई संसाधन नहीं बदला है, तो सर्वर 304 लौटाता है और क्लाइंट सिंक्रनाइज़ेशन पूरा करता है। यदि परिवर्तन हैं, तो सर्वर केवल संशोधित संसाधन लौटाता है। इस दृष्टिकोण को डेल्टा सिंक्रनाइज़ेशन कहा जाता है और यह सीमित ट्रैफ़िक वाले मोबाइल उपकरणों के लिए अत्यंत महत्वपूर्ण है।
आशावादी लॉकिंग परिदृश्यों में, ETag का उपयोग Lost Update विरोधों को रोकने के लिए किया जाता है। जब कोई क्लाइंट संसाधन को अपडेट करने के लिए PUT अनुरोध भेजता है, तो वह If-Match: “etag” हेडर शामिल करता है। यदि ETag मेल नहीं खाता (किसी अन्य क्लाइंट ने पहले ही संसाधन संशोधित कर दिया है), तो सर्वर 412 Precondition Failed के साथ प्रतिक्रिया करता है, और क्लाइंट को वर्तमान संस्करण पुनः लाना होगा और संशोधन पुनः प्रयास करना होगा। यह दृष्टिकोण डेटाबेस-स्तरीय लॉक के बिना डेटा स्थिरता सुनिश्चित करता है।
ऑफ़लाइन मोड वाली वितरित प्रणालियों के लिए, ETag का उपयोग विरोध समाधान के साथ संयोजन में किया जाता है। क्लाइंट सभी संसाधनों के लिए वर्तमान ETag प्राप्त करके सिंक्रनाइज़ करता है। परिवर्तन भेजते समय, सर्वर If-Match की जाँच करता है — यदि ETag मेल नहीं खाता, तो एक विरोध दर्ज किया जाता है जिसे चुनी गई रणनीति (LWW, Merge) के अनुसार हल किया जाता है। Postman API Report (2025) के अनुसार, मोबाइल एप्लिकेशन के लिए 67% प्रोडक्शन REST API संस्करण मान्यता के प्राथमिक तंत्र के रूप में ETag का उपयोग करते हैं।
अक्सर पूछे जाने वाले प्रश्न
ETag HTTP हेडर क्या है?
ETag एक HTTP प्रतिक्रिया हेडर है जिसमें संसाधन संस्करण का अद्वितीय पहचानकर्ता होता है। क्लाइंट इसका उपयोग सशर्त अनुरोधों के लिए करता है: यदि संसाधन नहीं बदला है, तो सर्वर प्रतिक्रिया निकाय के बिना 304 Not Modified लौटाता है, जिससे ट्रैफ़िक बचता है।
ETag और Last-Modified में क्या अंतर है?
ETag सटीक तुलना के लिए सामग्री हैश का उपयोग करता है। Last-Modified सेकंड सटीकता के साथ संशोधन तिथि पर आधारित है। ETag वास्तविक परिवर्तनों का पता लगाने के लिए अधिक विश्वसनीय है और If-Match के माध्यम से आशावादी लॉकिंग का समर्थन करता है।
मजबूत और कमजोर ETag क्या हैं?
मजबूत ETag (बिना उपसर्ग) संसाधनों को बाइट-दर-बाइट अलग करते हैं। कमजोर ETag (W/ उपसर्ग के साथ) शब्दार्थ समतुल्यता की अनुमति देते हैं। मजबूत ETag रेंज अनुरोधों के लिए आवश्यक हैं, कमजोर गतिशील रूप से उत्पन्न सामग्री के लिए।
ETag मोबाइल सिंक्रनाइज़ेशन में कैसे मदद करता है?
ETag ट्रैफ़िक को 80–90% कम करता है: क्लाइंट If-None-Match के माध्यम से सभी संसाधनों की ताज़गी की जाँच करता है, केवल बदले हुए संसाधनों को डाउनलोड करता है। ETag के बिना, क्लाइंट प्रत्येक सिंक्रनाइज़ेशन पर पूर्ण डेटा डाउनलोड करेगा, ट्रैफ़िक और बैटरी बर्बाद करेगा।
सर्वर पर ETag कैसे कार्यान्वित करें?
सर्वर ETag की गणना प्रतिक्रिया सामग्री के हैश (MD5, SHA-256) के रूप में करता है या डेटाबेस से रिकॉर्ड संस्करण संख्या का उपयोग करता है। Spring Boot में, @Cacheable एनोटेशन etag = true के साथ पर्याप्त है। Express.js में, etag मिडलवेयर डिफ़ॉल्ट रूप से सक्षम है।
सारांश
- ETag सामग्री हैश या संस्करण संख्या पर आधारित संसाधन संस्करण मान्यता के लिए एक HTTP हेडर है।
- सशर्त अनुरोध — क्लाइंट संग्रहीत ETag के साथ If-None-Match भेजता है, सर्वर अपरिवर्तित होने पर 304 के साथ प्रतिक्रिया करता है।
- ETag प्रकार — मजबूत (बाइट-दर-बाइट, रेंज अनुरोधों के लिए) और कमजोर (शब्दार्थ समतुल्यता, W/ उपसर्ग)।
- लाभ — ETag Last-Modified से अधिक सटीक है क्योंकि हैश समय की परवाह किए बिना किसी भी सामग्री संशोधन पर बदलता है।
- आशावादी लॉकिंग — If-Match के माध्यम से, ETag समवर्ती संसाधन संपादन के दौरान Lost Update विरोधों को रोकता है।
- डेल्टा सिंक्रनाइज़ेशन — ETag सिंक योजनाओं को शक्ति प्रदान करता है जहाँ केवल बदले हुए संसाधन प्रेषित होते हैं।
- अनुशंसा — मोबाइल एप्लिकेशन के लिए REST API में हमेशा ETag जोड़ें। CDN और प्रॉक्सी सर्वर संगतता के लिए Last-Modified के साथ संयोजित करें।
हम एक मोबाइल एप्लिकेशन टर्नकी विकसित करेंगे
IT Sectr 2017 से स्टार्टअप और व्यवसायों के लिए iOS और Android एप्लिकेशन बनाता है। हम आपको सलाह देंगे और सर्वोत्तम समाधान प्रस्तावित करेंगे।
यह भी पढ़ें