ایپلیکیشنز میں 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 کے ساتھ مشروط درخواستیں موبائل ایپلیکیشنز کی مطابقت پذیری کے دوران ڈیٹا کا حجم کم کرتی ہیں کیونکہ رسپانس باڈی منتقل نہیں ہوتی۔
- مضبوط اور کمزور ETags — مضبوط مواد کو بائٹ بہ بائٹ ممتاز کرتے ہیں، کمزور وسائل کی معنوی برابری کی اجازت دیتے ہیں۔
- استعمال — 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 کی اقسام: مضبوط اور کمزور شناخت کنندگان
مضبوط ETags (strong ETag) ایسے شناخت کنندگان ہیں جو مواد میں کسی بھی تبدیلی پر تبدیل ہوتے ہیں، بشمول معمولی تبدیلیاں (خالی جگہیں، فارمیٹنگ)۔ فارمیٹ: “abc123def” (ڈبل کوٹس میں، بغیر کسی سابقے کے)۔ مضبوط ETags اس بات کی ضمانت دیتے ہیں کہ وسائل بائٹ بہ بائٹ تبدیل نہیں ہوا۔ وہ رینج درخواستوں (Range requests) اور جزوی ڈاؤن لوڈز کی سالمیت کی جانچ کے لیے لازمی ہیں۔
کمزور ETags (weak ETag) W/ سابقے والے شناخت کنندگان ہیں، مثال کے طور پر W/“abc123def”۔ وہ اجازت دیتے ہیں کہ وسائل معنوی طور پر برابر ہے چاہے بائٹ نمائندگی مختلف ہو۔ کمزور ETags ان سرورز کے لیے مفید ہیں جو مختلف خالی جگہوں یا فارمیٹنگ لیکن ایک ہی معنی کے ساتھ متحرک طور پر رسپانس تیار کرتے ہیں۔ تاہم، کمزور ETags رینج درخواستوں کو سپورٹ نہیں کرتے۔
ETag اقسام کا موازنہ:
| خصوصیت | مضبوط ETag | کمزور ETag |
|---|---|---|
| فارمیٹ | “hash” | W/“hash” |
| حساسیت | بائٹ بہ بائٹ | معنوی |
| رینج درخواستیں | معاون | غیر معاون |
| CDN کیشنگ | مثالی | محدود |
| مطابقت پذیری | اعلیٰ درستگی | تصادم کی اجازت |
ETag بمقابلہ Last-Modified: کس کا انتخاب کریں
Last-Modified ایک HTTP ہیڈر ہے جو وسائل میں آخری ترمیم کی تاریخ اور وقت بتاتا ہے۔ کلائنٹ اسے If-Modified-Since ہیڈر میں واپس بھیجتا ہے۔ Last-Modified کو نافذ کرنا آسان ہے (سرور کو صرف تاریخ کی ضرورت ہے)، لیکن اس کی بنیادی حدود ہیں: ایک سیکنڈ کی ریزولوشن (ایک ہی سیکنڈ میں دو تبدیلیاں الگ نہیں کی جا سکتیں) اور جب ٹائم اسٹیمپ ایک جیسا ہو تو مواد کی تبدیلی کا تعین کرنے میں ناکامی (مثال کے طور پر، بیک اپ بحالی کے بعد)۔
ETag ان مسائل کو حل کرتا ہے: مواد کا ہیش وقت سے آزاد ہو کر کسی بھی ترمیم پر تبدیل ہوتا ہے۔ لہٰذا، جدید REST APIs دونوں ہیڈرز کا امتزاج استعمال کرتی ہیں: ETag درست توثیق کے لیے اور Last-Modified CDN پر تخمینی فلٹرنگ کے لیے۔ 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 تنازع کے حل کے ساتھ مل کر استعمال ہوتا ہے۔ کلائنٹ تمام وسائل کے موجودہ ETags حاصل کر کے مطابقت پذیری کرتا ہے۔ تبدیلیاں بھیجتے وقت، سرور If-Match چیک کرتا ہے — اگر ETag مماثل نہیں ہے، تو ایک تنازع ریکارڈ کیا جاتا ہے جو منتخب حکمت عملی (LWW، Merge) کے مطابق حل کیا جاتا ہے۔ Postman API Report (2025) کے مطابق، موبائل ایپلیکیشنز کے لیے 67% پروڈکشن REST APIs ورژن توثیق کے بنیادی طریقہ کار کے طور پر ETag استعمال کرتی ہیں۔
اکثر پوچھے گئے سوالات
ETag HTTP ہیڈر کیا ہے؟
ETag ایک HTTP رسپانس ہیڈر ہے جس میں وسائل کے ورژن کا منفرد شناخت کنندہ ہوتا ہے۔ کلائنٹ اسے مشروط درخواستوں کے لیے استعمال کرتا ہے: اگر وسائل تبدیل نہیں ہوا، سرور رسپانس باڈی کے بغیر 304 Not Modified واپس کرتا ہے، ٹریفک بچاتا ہے۔
ETag اور Last-Modified میں کیا فرق ہے؟
ETag درست موازنہ کے لیے مواد کا ہیش استعمال کرتا ہے۔ Last-Modified سیکنڈ کی درستگی کے ساتھ ترمیم کی تاریخ پر مبنی ہے۔ ETag حقیقی تبدیلیوں کا پتہ لگانے میں زیادہ قابل اعتماد ہے اور If-Match کے ذریعے امید پرستانہ لاکنگ کو سپورٹ کرتا ہے۔
مضبوط اور کمزور ETags کیا ہیں؟
مضبوط ETags (بغیر سابقے کے) وسائل کو بائٹ بہ بائٹ ممتاز کرتے ہیں۔ کمزور ETags (W/ سابقے کے ساتھ) معنوی برابری کی اجازت دیتے ہیں۔ مضبوط رینج درخواستوں کے لیے ضروری ہیں، کمزور متحرک طور پر تیار کردہ مواد کے لیے۔
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 اقسام — مضبوط (بائٹ بہ بائٹ، Range درخواستوں کے لیے) اور کمزور (معنوی برابری، W/ سابقہ)۔
- فائدہ — ETag Last-Modified سے زیادہ درست ہے کیونکہ ہیش وقت سے آزاد ہو کر کسی بھی مواد کی تبدیلی پر تبدیل ہوتا ہے۔
- امید پرستانہ لاکنگ — If-Match کے ذریعے، ETag بیک وقت وسائل کی تدوین کے دوران Lost Update تنازعات کو روکتا ہے۔
- ڈیلٹا مطابقت پذیری — ETag مطابقت پذیری سکیموں کو طاقت دیتا ہے جہاں صرف تبدیل شدہ وسائل منتقل ہوتے ہیں۔
- سفارش — موبائل ایپلیکیشنز کے لیے REST API میں ہمیشہ ETag شامل کریں۔ CDN اور پراکسی سرورز کے ساتھ مطابقت کے لیے Last-Modified کے ساتھ ملائیں۔
ہم ایک موبائل ایپلیکیشن ٹرنکی تیار کریں گے
IT Sectr 2017 سے اسٹارٹ اپس اور کاروبار کے لیے iOS اور Android ایپلیکیشنز بناتا ہے۔ ہم آپ کو مشورہ دیں گے اور بہترین حل تجویز کریں گے۔
مزید پڑھیں