ETag, bir kaynak sürümünün benzersiz tanımlayıcısını içeren bir HTTP yanıt başlığıdır. Sunucu, ETag'i bir içerik karması veya sürüm numarası olarak oluşturur ve verilerle birlikte istemciye döndürür. Sonraki isteklerde, istemci bu tanımlayıcıyı If-None-Match başlığında göndererek sunucunun kaynağın değişip değişmediğini kontrol etmesine olanak tanır. MDN Web Docs, 2025'e göre ETag, HTTP'deki koşullu GET istek mekanizmasının temelidir. ETag ile koşullu istekler, mobil uygulama senkronizasyonu sırasında aktarılan veri miktarını %90'a kadar azaltır.
Anahtar Noktalar
ETag (Entity Tag), önbelleğe alınmış kaynakları doğrulayan, koşullu başlık ailesinden bir HTTP başlığıdır. Sunucu, ETag'i bir karma (MD5, SHA-256) veya kaynak sürüm numarası olarak hesaplar ve bir GET isteğine yanıt olarak döndürür. İstemci, ETag'i verilerle birlikte saklar ve sonraki isteklerde If-None-Match başlığında gönderir. Kaynak içeriği değişmemişse, sunucu yanıt gövdesi olmadan 304 Not Modified durumuyla yanıt verir.
Mobil uygulamalar için ETag, indirilen veri miktarını azalttığı için kritik öneme sahiptir. Her başlatmada veya senkronizasyonda, uygulama If-None-Match isteğiyle kaynakların güncelliğini kontrol eder — tam veri yüklemek yerine 304 alır ve yerel kopyayı kullanır. Google Chrome Team'e (2024) göre, mobil API'lerde ETag kullanımı, listeler için ortalama yanıt boyutunu %87 ve tek tek nesneler için %94 oranında azaltır.
ETag sunucu tarafında oluşturulur ve belirleyici (aynı içerik için aynı, paylaşılan önbellekler için yararlı) veya yanıt başına benzersiz (katı doğrulama için) olabilir. Mobil senkronizasyon için tasarlanmış REST API'lerinde en yaygın kombinasyon, bir içerik karması ve veritabanındaki kayıt sürüm numarasıdır.
Güçlü ETag'ler (strong ETag), önemsiz değişiklikler (boşluklar, biçimlendirme) dahil olmak üzere içerikteki herhangi bir değişiklikte değişen tanımlayıcılardır. Biçim: “abc123def” (çift tırnak içinde, ön ek yok). Güçlü ETag'ler, kaynağın bayt bayt değişmediğini garanti eder. Aralık istekleri (Range requests) ve kısmi indirmelerin bütünlüğünü kontrol etmek için zorunludurlar.
Zayıf ETag'ler (weak ETag), W/ ön ekine sahip tanımlayıcılardır, örneğin W/“abc123def”. Bayt temsili farklı olsa bile kaynağın anlamsal olarak eşdeğer olmasına izin verirler. Zayıf ETag'ler, farklı boşluklar veya biçimlendirme ancak aynı anlamla dinamik olarak yanıt oluşturan sunucular için kullanışlıdır. Ancak zayıf ETag'ler aralık isteklerini desteklemez.
ETag türlerinin karşılaştırması:
| Özellik | Güçlü ETag | Zayıf ETag |
|---|---|---|
| Biçim | “hash” | W/“hash” |
| Duyarlılık | Bayt bayt | Anlamsal |
| Range istekleri | Desteklenir | Desteklenmez |
| CDN önbelleği | İdeal | Sınırlı |
| Senkronizasyon | Yüksek hassasiyet | Çakışmalara izin verir |
Last-Modified, kaynağın son değiştirilme tarihini ve saatini gösteren bir HTTP başlığıdır. İstemci bunu If-Modified-Since başlığında geri gönderir. Last-Modified'ın uygulanması daha basittir (sunucunun yalnızca bir tarihe ihtiyacı vardır), ancak temel sınırlamaları vardır: bir saniyelik çözünürlük (aynı saniyedeki iki değişiklik ayırt edilemez) ve zaman damgası aynıysa içeriğin değişip değişmediğini belirleyememe (örneğin, bir yedekten geri yükleme sonrası).
ETag bu sorunları çözer: içerik karması, zamandan bağımsız olarak her değişiklikte değişir. Bu nedenle, modern REST API'leri her iki başlığın bir kombinasyonunu kullanır: ETag kesin doğrulama için ve Last-Modified CDN'de yaklaşık filtreleme için. Apache HTTP Server ve Nginx, varsayılan olarak statik dosyalar için her iki başlığı da oluşturur.
Senkronizasyonlu mobil uygulamalar için ETag daha kritiktir çünkü düzenleme çakışmalarını tespit etmeye olanak tanır. Bir istemci If-Match: “etag” ile bir PUT isteği gönderdiğinde, kaynak başka bir istemci tarafından değiştirilmişse sunucu isteği reddeder (iyimser kilitleme). Last-Modified, saniye düzeyindeki hassasiyet nedeniyle bu tür bir güvenilirliği garanti edemez.
Bir istemci tarafı uygulamasına bakalım — Retrofit ve OkHttp ile Kotlin kullanarak mobil uygulamada ETag kullanımı. Her GET isteğinde, istemci yanıttan ETag'i kaydeder ve sonraki istekte bunu If-None-Match başlığında gönderir. Sunucu 304 döndürürse, veriler yeniden indirilmez.
ETag önbellekleme ile OkHttp istemcisi kurulumu:
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}"))
}
}
}
İstemci, başarılı bir 200 yanıtından sonra ETag'i kaydeder ve bir sonraki istekte If-None-Match başlığında gönderir. 304 yanıtında, istemci yerel sürümün güncel olduğunu bilir ve yeniden indirmek için trafik harcamaz. Bu model, sık istenen kaynaklar için mobil uygulamanın ağ maliyetlerini %80–90 oranında azaltır.
ETag, REST API'leri ile mobil uygulama senkronizasyonunu optimize etmek için anahtar bir mekanizmadır. Standart bir senkronizasyon şemasında, istemci önce ETag doğrulaması ile kaynakların bir listesini ister — hiçbir kaynak değişmemişse, sunucu 304 döndürür ve istemci senkronizasyonu tamamlar. Değişiklik varsa, sunucu yalnızca değiştirilen kaynakları döndürür. Bu yaklaşıma delta senkronizasyonu denir ve sınırlı trafiğe sahip mobil cihazlar için kritik öneme sahiptir.
İyimser kilitleme senaryolarında ETag, Lost Update çakışmalarını önlemek için kullanılır. Bir istemci bir kaynağı güncellemek için PUT isteği gönderdiğinde, If-Match: “etag” başlığını ekler. ETag eşleşmezse (başka bir istemci kaynağı zaten değiştirdiyse), sunucu 412 Precondition Failed ile yanıt verir ve istemcinin geçerli sürümü yeniden alması ve değişikliği yeniden denemesi gerekir. Bu yaklaşım, veritabanı düzeyinde kilitler olmadan veri tutarlılığını sağlar.
Çevrimdışı modlu dağıtık sistemler için ETag, Çakışma Çözümü ile kombinasyon halinde kullanılır. İstemci, tüm kaynaklar için geçerli ETag'leri alarak senkronize olur. Değişiklikleri gönderirken sunucu If-Match'i kontrol eder — ETag eşleşmezse, bir çakışma kaydedilir ve seçilen stratejiye (LWW, Merge) göre çözülür. Postman API Report (2025)'e göre, mobil uygulamalar için üretim REST API'lerinin %67'si birincil sürüm doğrulama mekanizması olarak ETag kullanmaktadır.
Sıkça Sorulan Sorular
ETag, kaynak sürümünün benzersiz tanımlayıcısını içeren bir HTTP yanıt başlığıdır. İstemci bunu koşullu istekler için kullanır: kaynak değişmemişse sunucu yanıt gövdesi olmadan 304 Not Modified döndürerek trafikten tasarruf sağlar.
ETag kesin karşılaştırma için içerik karması kullanır. Last-Modified saniye hassasiyetinde değişiklik tarihine dayanır. ETag, gerçek değişiklikleri tespit etmede daha güvenilirdir ve If-Match aracılığıyla iyimser kilitlemeyi destekler.
Güçlü ETag'ler (ön ek yok) kaynakları bayt bayt ayırt eder. Zayıf ETag'ler (W/ ön eki ile) anlamsal eşdeğerliğe izin verir. Güçlü olanlar Range istekleri için gereklidir, zayıf olanlar dinamik olarak oluşturulan içerik içindir.
ETag trafiği %80–90 oranında azaltır: istemci If-None-Match aracılığıyla tüm kaynakların güncelliğini kontrol eder ve yalnızca değişenleri indirir. ETag olmadan, istemci her senkronizasyonda tam veri indirir, trafik ve pil israfına neden olur.
Sunucu ETag'i yanıt içeriğinin karması (MD5, SHA-256) olarak hesaplar veya veritabanından kayıt sürüm numarası kullanır. Spring Boot'da @Cacheable ek açıklaması etag = true ile yeterlidir. Express.js'de etag ara yazılımı varsayılan olarak etkindir.
Özet
Anahtar teslim bir mobil uygulama geliştireceğiz
IT Sectr, 2017'den beri girişimler ve işletmeler için iOS ve Android uygulamaları oluşturmaktadır. Size danışmanlık yapacak ve en iyi çözümü önereceğiz.
Ayrıca okuyun