ETag — resurs versiyasının unikal identifikatorunu ehtiva edən HTTP cavab başlığı. Server ETag-i məzmunun heşi və ya versiya nömrəsi kimi yaradır və məlumatlarla birlikdə müştəriyə qaytarır. Növbəti sorğularda müştəri bu identifikatoru If-None-Match başlığında göndərir və server resursun dəyişib-dəyişmədiyini yoxlaya bilər. MDN Web Docs, 2025-ə görə, ETag HTTP-də şərti GET sorğuları mexanizminin əsasını təşkil edir. ETag ilə şərti sorğular mobil tətbiqlərin sinxronizasiyası zamanı ötürülən məlumatların həcmini 90% azaldır.
Əsas məqamlar
ETag (Entity Tag) — keşlənmiş resursların validasiyasını təmin edən şərti başlıqlar ailəsindən HTTP başlığı. Server ETag-i heş-cəmi (MD5, SHA-256) və ya resursun versiya nömrəsi kimi hesablayır və GET sorğusuna cavabda qaytarır. Müştəri ETag-i məlumatlarla birlikdə saxlayır və təkrar sorğuda onu If-None-Match başlığında göndərir. Resursun məzmunu dəyişməyibsə, server cavabın gövdəsi olmadan 304 Not Modified statusu ilə cavab verir.
Mobil tətbiqlər üçün ETag kritik əhəmiyyət daşıyır, çünki yüklənən məlumatların həcmini azaldır. Hər işə salınma və ya sinxronizasiyada tətbiq resursların aktuallığını If-None-Match ilə sorğu vasitəsilə yoxlayır — tam məlumat yükləmək əvəzinə 304 alır və lokal nüsxədən istifadə edir. Google Chrome Team (2024) məlumatlarına görə, mobil API-lərdə ETag istifadəsi siyahılar üçün orta cavab həcmini 87%, ayrı-ayrı obyektlər üçün 94% azaldır.
ETag server tərəfindən yaradılır və həm deterministik (eyni məzmun üçün eyni, bu paylaşılan keşlər üçün faydalıdır), həm də hər cavab üçün unikal (ciddi validasiya üçün) ola bilər. Mobil sinxronizasiya üçün nəzərdə tutulmuş REST API-lərdə ən çox məzmun heşi və verilənlər bazasındakı yazının versiya nömrəsinin kombinasiyası istifadə olunur.
Güclü ETag (strong ETag) — məzmundakı hər hansı dəyişiklikdə, o cümlədən əhəmiyyətsizlərdə (boşluqlar, formatlaşdırma) dəyişən identifikatorlar. Format: "abc123def" (qoşa dırnaq içərisində, prefiksiz). Güclü ETag resursun bayt-bayt dəyişmədiyinə zəmanət verir. Onlar diapazon sorğuları (Range requests) və qismən yükləmələrin bütövlüyünün yoxlanılması üçün məcburidir.
Zəif ETag (weak ETag) — W/ prefiksi olan identifikatorlar, məsələn W/"abc123def". Onlar bayt təsviri fərqli olsa belə, resursun semantik ekvivalent olduğunu qəbul edir. Zəif ETag müxtəlif boşluqlar və ya formatlaşdırma ilə dinamik cavablar yaradan serverlər üçün faydalıdır. Lakin zəif ETag diapazon sorğularını dəstəkləmir.
ETag növlərinin müqayisəsi:
| Xüsusiyyət | Güclü ETag | Zəif ETag |
|---|---|---|
| Format | "hash" | W/"hash" |
| Həssaslıq | Bayt-bayt | Semantik |
| Diapazon sorğuları | Dəstəklənir | Dəstəklənmir |
| CDN keşləmə | İdeal | Məhdud |
| Sinxronizasiya | Yüksək dəqiqlik | Toqquşmalara icazə verir |
Last-Modified — resursun son dəyişmə tarixini və vaxtını göstərən HTTP başlığı. Müştəri onu If-Modified-Since başlığında geri göndərir. Last-Modified tətbiqi daha sadədir (serverə yalnız tarix lazımdır), lakin fundamental məhdudiyyətləri var: bir saniyə dəqiqlik (bir saniyə ərzində iki dəyişiklik fərqlənmir) və eyni vaxtda məzmunun dəyişib-dəyişmədiyini müəyyən edə bilməmək (məsələn, backup-dan bərpa edildikdən sonra).
ETag bu problemləri həll edir: məzmunun heşi vaxtdan asılı olmayaraq hər dəyişiklikdə dəyişir. Buna görə müasir REST API-lər hər iki başlığın kombinasiyasından istifadə edir: ETag dəqiq validasiya üçün, Last-Modified isə CDN-də təxmini filtrləmə üçün. Apache HTTP Server və Nginx statik fayllar üçün hər iki başlığı defolt olaraq yaradır.
Sinxronizasiyalı mobil tətbiqlər üçün ETag daha vacibdir, çünki redaktə münaqişələrini aşkarlamağa imkan verir. Müştəri If-Match: "etag" başlığı ilə PUT sorğusu göndərirsə, resurs başqa müştəri tərəfindən dəyişdirilibsə server sorğunu rədd edir (optimistik kilidləmə). Last-Modified saniyə dəqiqliyi səbəbindən belə etibarlılığı təmin edə bilməz.
Mobil tətbiqdə ETag-in müştəri tərəfindən tətbiqini Kotlin-də Retrofit və OkHttp istifadə edərək nəzərdən keçirək. Hər GET sorğusunda müştəri cavabdan ETag-i saxlayır, növbəti sorğuda isə onu If-None-Match başlığında göndərir. Server 304 qaytararsa, məlumatlar təkrar yüklənmir.
ETag keşləmə ilə OkHttp müştərisinin konfiqurasiyası:
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}"))
}
}
}
Müştəri uğurlu 200 cavabından sonra ETag-i saxlayır və növbəti sorğuda onu If-None-Match başlığında göndərir. 304-də müştəri lokal versiyanın aktual olduğunu bilir və məlumatların təkrar yüklənməsinə trafik sərf etmir. Bu nümunə tez-tez sorğulanan resurslar üçün mobil tətbiqin şəbəkə xərclərini 80–90% azaldır.
ETag mobil tətbiqlərin REST API ilə sinxronizasiyasının optimallaşdırılması üçün əsas mexanizmdir. Standart sinxronizasiya sxemində müştəri əvvəlcə ETag validasiyası ilə resursların siyahısını sorğulayır — heç bir resurs dəyişməyibsə, server 304 qaytarır və müştəri sinxronizasiyanı bitirir. Dəyişikliklər varsa, server yalnız dəyişdirilmiş resursları qaytarır. Bu yanaşma delta-sinxronizasiya adlanır və məhdud trafikli mobil cihazlar üçün kritik əhəmiyyət daşıyır.
Optimistik kilidləmə ssenarilərində ETag Lost Update münaqişələrinin qarşısını almaq üçün istifadə olunur. Müştəri resursu yeniləmək üçün PUT sorğusu göndərdikdə, If-Match: "etag" başlığını əlavə edir. ETag uyğun gəlmirsə (başqa müştəri resursu artıq dəyişdiribsə), server 412 Precondition Failed ilə cavab verir və müştəri aktual versiyanı yenidən yükləyib dəyişikliyi təkrarlamalıdır. Bu yanaşma verilənlər bazası səviyyəsində kilidləmə olmadan məlumatların ardıcıllığını təmin edir.
Oflayn rejimli paylanmış sistemlər üçün ETag Conflict Resolution ilə birlikdə istifadə olunur. Müştəri bütün resurslar üçün cari ETag-ləri alaraq sinxronizasiya edir. Dəyişiklikləri göndərərkən server If-Match-i yoxlayır — ETag uyğun gəlməzsə, seçilmiş strategiyaya (LWW, Merge) uyğun həll edilən konflikt qeydə alınır. Postman API Report (2025) məlumatlarına görə, mobil tətbiqlər üçün production REST API-lərin 67%-i ETag-dan əsas versiya validasiya mexanizmi kimi istifadə edir.
Tez-tez verilən suallar
ETag — resurs versiyasının unikal identifikatorunu ehtiva edən HTTP cavab başlığı. Müştəri onu şərti sorğular üçün istifadə edir: resurs dəyişməyibsə, server trafikə qənaət edərək cavabın gövdəsi olmadan 304 Not Modified qaytarır.
ETag dəqiq müqayisə üçün məzmun heşindən istifadə edir. Last-Modified saniyə dəqiqliyi ilə dəyişmə tarixinə əsaslanır. ETag real dəyişikliklərin aşkarlanmasında daha etibarlıdır və If-Match vasitəsilə optimistik kilidləməni dəstəkləyir.
Güclü ETag (prefiksiz) resursları bayt-bayt fərqləndirir. Zəif ETag (W/ prefiksi ilə) semantik ekvivalentliyə icazə verir. Güclü olanlar diapazon sorğuları üçün tələb olunur, zəiflər dinamik yaradılan məzmun üçündür.
ETag trafiki 80–90% azaldır: müştəri bütün resursların aktuallığını If-None-Match vasitəsilə yoxlayır, yalnız dəyişənləri yükləyir. ETag olmadan müştəri hər sinxronizasiyada tam məlumatları yükləyərək trafik və batareya sərf edərdi.
Server ETag-i cavab məzmununun heşi (MD5, SHA-256) kimi hesablayır və ya verilənlər bazasındakı yazının versiya nömrəsindən istifadə edir. Spring Boot-da @Cacheable annotasiyası etag = true ilə kifayətdir. Express.js-də etag middleware-i defolt olaraq aktivdir.
Nəticə
Açar təslim mobil tətbiq hazırlayacağıq
IT Sectr 2017-ci ildən startaplar və bizneslər üçün iOS və Android tətbiqləri yaradır. Sizə məsləhət verəcəyik və ən yaxşı həlli təklif edəcəyik.
Həm də oxuyun