ETag sa mga app — ano ito, layunin at prinsipyo
ETag — isang HTTP response header na naglalaman ng natatanging identifier ng bersyon ng resource. Ang server ay gumagawa ng ETag bilang hash ng nilalaman o numero ng bersyon at ibinabalik ito sa client kasama ng data. Sa mga susunod na kahilingan, ang client ay nagpapadala ng identifier na ito sa If-None-Match header, na nagpapahintulot sa server na suriin kung nagbago ang resource. Ayon sa MDN Web Docs, 2025, ang ETag ay ang batayan ng mekanismo ng conditional GET requests sa HTTP. Conditional requests na may ETag ay nagbabawas ng dami ng naililipat na data sa pag-sync ng mobile apps ng hanggang 90%.
Mga Pangunahing Punto
- ETag — HTTP header na naglalaman ng natatanging identifier ng bersyon ng resource, karaniwang hash ng nilalaman nito.
- If-None-Match — ipinapadala ng client ang naka-save na ETag, ibinabalik ng server ang 304 Not Modified kung hindi nagbago ang resource.
- Pagtipid sa trapiko — conditional requests na may ETag ay nagbabawas ng dami ng data sa pag-sync ng mobile apps dahil hindi ipinapadala ang body ng response.
- Malakas at mahinang ETag — ang malalakas ay nagkakaiba ng nilalaman byte-por-byte, ang mahihina ay pumapayag sa semantikong pagkakatumbas ng resource.
- Aplikasyon — ginagamit ang ETag sa REST API para sa pag-sync ng data, caching, at pagpigil sa mga conflict sa pag-edit.
Ano ang ETag sa HTTP at mobile apps?
ETag (Entity Tag) — HTTP header mula sa pamilya ng conditional headers na nagbibigay ng validation ng naka-cache na resources. Kinakalkula ng server ang ETag bilang hash sum (MD5, SHA-256) o numero ng bersyon ng resource at ibinabalik ito sa response sa GET request. Ini-save ng client ang ETag kasama ng data at sa susunod na kahilingan ay ipinapadala ito sa If-None-Match header. Kung hindi nagbago ang nilalaman ng resource, ang server ay tumutugon ng 304 Not Modified na walang body ng response.
Para sa mobile apps, ang ETag ay kritikal dahil binabawasan nito ang dami ng dina-download na data. Sa bawat paglunsad o pag-sync, sinusuri ng app ang pagiging bago ng resources gamit ang If-None-Match request — sa halip na i-download ang kumpletong data, natatanggap nito ang 304 at ginagamit ang lokal na kopya. Ayon sa Google Chrome Team (2024), ang paggamit ng ETag sa mobile APIs ay nagbabawas ng average na volume ng response ng 87% para sa mga listahan at 94% para sa mga indibidwal na bagay.
Ang ETag ay nabuo sa server side at maaaring maging deterministic (pareho para sa parehong nilalaman, kapaki-pakinabang para sa shared caches) at natatangi para sa bawat response (para sa mahigpit na validation). Sa REST APIs na dinisenyo para sa mobile synchronization, ang kombinasyon ng hash ng nilalaman at numero ng bersyon ng record sa database ang pinakamadalas gamitin.
Mga Uri ng ETag: malakas at mahinang identifier
Malakas na ETag (strong ETag) — mga identifier na nagbabago sa bawat pagbabago ng nilalaman, kasama na ang maliliit na pagbabago (espasyo, pag-format). Format: "abc123def" (sa mga panipi, walang prefix). Ginagarantiya ng malalakas na ETag na ang resource ay hindi nagbago byte-por-byte. Ang mga ito ay kinakailangan para sa range requests at para sa pagsuri ng integridad ng bahagyang pag-download.
Mahinang ETag (weak ETag) — mga identifier na may prefix na W/, halimbawa W/"abc123def". Pinapayagan nila na ang resource ay semantikong katumbas kahit na ang byte representation ay naiiba. Ang mahihinang ETag ay kapaki-pakinabang para sa mga server na dinamikong gumagawa ng mga response na may magkakaibang espasyo o format ngunit parehong kahulugan. Gayunpaman, ang mahihinang ETag ay hindi sumusuporta sa range requests.
Paghahambing ng mga uri ng ETag:
| Katangian | Malakas na ETag | Mahinang ETag |
|---|---|---|
| Format | "hash" | W/"hash" |
| Sensitivity | Byte-por-byte | Semantiko |
| Range requests | Sinusuportahan | Hindi sinusuportahan |
| CDN caching | Mainam | Limitado |
| Synchronization | Mataas na presisyon | Pinapayagan ang banggaan |
ETag laban sa Last-Modified: alin ang pipiliin
Last-Modified — HTTP header na nagpapahiwatig ng petsa at oras ng huling pagbabago ng resource. Ipinapadala ito pabalik ng client sa If-Modified-Since header. Ang Last-Modified ay mas simple ipatupad (ang server ay nangangailangan lamang ng petsa), ngunit may pangunahing limitasyon: isang segundong resolusyon (dalawang pagbabago sa isang segundo ay hindi matukoy) at kawalan ng kakayahang matukoy kung nagbago ang nilalaman sa parehong oras (halimbawa, pagkatapos ng pag-restore mula sa backup).
Nilulutas ng ETag ang mga problemang ito: ang hash ng nilalaman ay nagbabago sa bawat pagbabago anuman ang oras. Kaya naman ang mga modernong REST API ay gumagamit ng kombinasyon ng parehong header: ETag para sa eksaktong validation at Last-Modified para sa tinatayang pag-filter sa CDN. Ang Apache HTTP Server at Nginx ay default na gumagawa ng parehong header para sa mga static na file.
Para sa mobile apps na may synchronization, ang ETag ay mas kritikal dahil pinapayagan nito ang pagtuklas ng mga conflict sa pag-edit. Kung ang client ay nagpapadala ng PUT request na may If-Match: "etag" header, tinatanggihan ng server ang request kung ang resource ay binago ng ibang client (optimistic locking). Hindi magagarantiya ng Last-Modified ang ganitong pagiging maaasahan dahil sa segundong presisyon.
Mga halimbawa ng pagtatrabaho sa ETag sa Kotlin
Tingnan natin ang client implementation ng ETag sa isang mobile app sa Kotlin gamit ang Retrofit at OkHttp. Sa bawat GET request, ini-save ng client ang ETag mula sa response, at sa susunod na request ay ipinapadala ito sa If-None-Match header. Kung ang server ay nagbalik ng 304, ang data ay hindi dina-download muli.
Configuration ng OkHttp client na may ETag caching:
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}"))
}
}
}Ini-save ng client ang ETag pagkatapos ng matagumpay na 200 response at ipinapadala ito sa If-None-Match header sa susunod na request. Sa 304, alam ng client na ang lokal na bersyon ay bago at hindi nag-aaksaya ng trapiko sa muling pag-download ng data. Ang pattern na ito ay nagbabawas ng network costs ng mobile app ng 80–90% para sa madalas na hinihinging resources.
Papel ng ETag sa pag-sync ng mobile apps
Ang ETag ay isang pangunahing mekanismo para sa pag-optimize ng synchronization ng mobile apps sa REST API. Sa karaniwang synchronization scheme, ang client ay unang humihingi ng listahan ng resources na may ETag validation — kung walang resource na nagbago, ang server ay nagbabalik ng 304 at tinatapos ng client ang synchronization. Kung may mga pagbabago, ang server ay nagbabalik lamang ng mga binagong resource. Ang approach na ito ay tinatawag na delta synchronization at kritikal para sa mobile devices na may limitadong trapiko.
Sa mga scenario na may optimistic locking, ang ETag ay ginagamit para pigilan ang Lost Update conflicts. Kapag ang client ay nagpapadala ng PUT request para i-update ang resource, isinasama nito ang If-Match: "etag" header. Kung hindi tugma ang ETag (ibang client na ang nagbago ng resource), ang server ay tumutugon ng 412 Precondition Failed, at ang client ay dapat mag-download muli ng kasalukuyang bersyon at ulitin ang pagbabago. Ang approach na ito ay nagsisiguro ng consistency ng data nang walang locking sa antas ng database.
Para sa distributed systems na may offline mode, ang ETag ay ginagamit sa kombinasyon sa Conflict Resolution. Ang client ay nag-sync sa pamamagitan ng pagkuha ng kasalukuyang ETag para sa lahat ng resources. Kapag nagpapadala ng mga pagbabago, sinusuri ng server ang If-Match — kung hindi tugma ang ETag, may conflict na nare-record na niresolba ayon sa napiling strategy (LWW, Merge). Ayon sa Postman API Report (2025), 67% ng production REST APIs para sa mobile apps ay gumagamit ng ETag bilang pangunahing validation mechanism para sa mga bersyon.
Mga Madalas Itanong
Ano ang HTTP header na ETag?
ETag — HTTP response header na naglalaman ng natatanging identifier ng bersyon ng resource. Ginagamit ito ng client para sa conditional requests: kung hindi nagbago ang resource, ang server ay nagbabalik ng 304 Not Modified na walang body ng response, nakakatipid ng trapiko.
Ano ang pagkakaiba ng ETag at Last-Modified?
ETag ay gumagamit ng hash ng nilalaman para sa eksaktong paghahambing. Last-Modified ay batay sa petsa ng pagbabago na may isang segundong presisyon. Ang ETag ay mas maaasahan para sa pagtuklas ng totoong pagbabago at sumusuporta sa optimistic locking sa pamamagitan ng If-Match.
Ano ang malakas at mahinang ETag?
Malakas na ETag (walang prefix) ay nagkakaiba ng resources byte-por-byte. Mahinang ETag (may prefix na W/) ay pumapayag sa semantikong pagkakatumbas. Ang malalakas ay kinakailangan para sa range requests, ang mahihina para sa dinamikong nabuong nilalaman.
Paano nakakatulong ang ETag sa mobile synchronization?
Binabawasan ng ETag ang trapiko ng 80–90%: sinusuri ng client ang pagiging bago ng lahat ng resources sa pamamagitan ng If-None-Match, dina-download lamang ang mga nagbago. Kung walang ETag, dina-download ng client ang kumpletong data sa bawat synchronization, nag-aaksaya ng trapiko at baterya.
Paano i-implement ang ETag sa server?
Kinakalkula ng server ang ETag bilang hash (MD5, SHA-256) ng nilalaman ng response o ginagamit ang numero ng bersyon ng record mula sa database. Sa Spring Boot, ang annotation na @Cacheable na may etag = true ay sapat na. Sa Express.js, ang etag middleware ay default na naka-enable.
Buod
- ETag — HTTP header para sa validation ng mga bersyon ng resources, batay sa hash ng nilalaman o numero ng bersyon.
- Conditional requests — client ay nagpapadala ng If-None-Match na may naka-save na ETag, server ay tumutugon ng 304 kung walang pagbabago.
- Mga Uri ng ETag — malakas (byte-por-byte, para sa range requests) at mahina (semantikong pagkakatumbas, prefix W/).
- Bentahe — Ang ETag ay mas tumpak kaysa Last-Modified dahil ang hash ay nagbabago sa bawat pagbabago ng nilalaman anuman ang oras.
- Optimistic locking — sa pamamagitan ng If-Match, pinipigilan ng ETag ang Lost Update conflicts sa sabay na pag-edit ng resources.
- Delta synchronization — mga synchronization scheme na batay sa ETag kung saan ang mga nagbago lamang na resources ang naililipat.
- Rekomendasyon — palaging magdagdag ng ETag sa REST API para sa mobile apps. Pagsamahin sa Last-Modified para sa compatibility sa CDN at proxy servers.
Gagawa kami ng mobile application na turnkey
Gumagawa ang IT Sectr ng mga iOS at Android application para sa mga startup at negosyo mula noong 2017. Magpapayo kami sa iyo at magmumungkahi ng pinakamahusay na solusyon.
Basahin din