Conditional GET: ano ito, mekanismo ng kondisyonal na kahilingan

Ano ang Conditional GET sa HTTP?

Conditional GET — ay isang GET na kahilingan na naglalaman ng isa o higit pang kondisyonal na header, batay sa kung saan nagpapasya ang server kung magbabalik ng buong tugon o 304 Not Modified status lamang. Ang pangunahing layunin ay iwasan ang pagpapadala ng body ng tugon kung hindi nagbago ang resource mula noong huling kahilingan. Ito ay isang pangunahing mekanismo ng HTTP caching, na tinukoy sa RFC 7232 specification.

Para sa mga mobile application, ang Conditional GET ay isa sa mga pinaka-epektibong paraan upang i-optimize ang trapiko sa network. Karaniwang senaryo: sa pagbubukas ng application, nagpapadala ang client ng serye ng kondisyonal na GET na kahilingan upang i-load ang feed, profile, at mga setting. Kung hindi nagbago ang data, ang application ay tumatanggap ng 304 at gumagamit ng lokal na kopya. Ito ay tumatagal ng millisecond sa halip na segundo at hindi gumagamit ng mobile data.

Ayon sa Google Web Fundamentals (2025), ang pagpapatupad ng kondisyonal na GET na mga kahilingan sa isang mobile application ay nagbabawas ng average na oras ng pag-load ng 40–60% para sa mga paulit-ulit na pagbisita at nagpapababa ng konsumo ng data ng 70–90% para sa mga pahinang may madalang na update. Ang epekto ay lalong kapansin-pansin sa mabagal na koneksyon (3G, Edge), kung saan mahalaga ang bawat byte.

Paano gumagana ang kondisyonal na GET na kahilingan

Ang proseso ay binubuo ng tatlong hakbang. Una — nagpapadala ang client ng karaniwang GET na kahilingan, nagbabalik ang server ng resource kasama ang caching headers (ETag, Last-Modified). Pangalawa — ini-save ng client ang resource at ang mga validator nito nang lokal. Pangatlo — sa paulit-ulit na kahilingan, nagpapadala ang client ng GET na may If-None-Match (para sa ETag) at/o If-Modified-Since (para sa Last-Modified). Sinusuri ng server ang mga validator at tumugon ng 304 kung hindi nagbago ang resource, o 200 na may bagong data.

Gumagamit ang server ng prioridad ng ETag kaysa Last-Modified kapag parehong present ang mga header. Ito ay dahil ang ETag ay nagbibigay ng mas tumpak na validation — ang hash ng nilalaman ay nagbabago sa anumang pagbabago, samantalang ang Last-Modified ay may resolusyon na isang segundo. Kung tugma ang ETag, agad na nagbabalik ang server ng 304, nang hindi sinusuri ang Last-Modified.

Halimbawa ng buong cycle ng Conditional GET sa pagkakasunod-sunod ng mga kahilingan:

// Hakbang 1: Unang kahilingan — kunin ang data at ETag
GET /api/profile
Response: 200 OK
ETag: "33a64df551425fcc55e"
Body: { "name": "Alice" }

// Hakbang 2: Ulitin ang kahilingan — gamit ang If-None-Match
GET /api/profile
If-None-Match: "33a64df551425fcc55e"
Response: 304 Not Modified
// Wala ang body ng tugon — gamitin ang lokal na kopya

Sa pangalawang kahilingan, inihahambing ng server ang ETag mula sa If-None-Match sa kasalukuyang hash ng resource. Sa pagtutugma, ibinabalik ang 304 na walang body — patuloy na ginagamit ng client ang naka-cache na data. Ito ang esensya ng Conditional GET: minimum na trapiko na may maximum na pagiging bago ng data.

Conditional GET kumpara sa karaniwang GET

Ang karaniwang GET na kahilingan ay palaging nagbabalik ng buong 200 OK na tugon na may body. Kahit na hindi nagbago ang resource, ipinapadala muli ng server ang lahat ng data. Ito ay katanggap-tanggap para sa maliliit na resource o madalang na mga kahilingan, ngunit para sa mga mobile application na may daan-daang kahilingan sa bawat pagbukas, ang ganitong approach ay humahantong sa labis na konsumo ng data at baterya.

Conditional GET ay nagdaragdag ng overhead sa anyo ng mga header (karaniwang 50–200 byte bawat kahilingan), ngunit nakakatipid ng kilobyte at megabyte sa 304 na tugon. Kung mas malaki ang resource, mas kapaki-pakinabang ang kondisyonal na kahilingan. Para sa mga imahe, listahan ng data, at JSON dokumento na may sukat na 10 KB pataas, ang Conditional GET ay kumikita mula sa unang paulit-ulit na kahilingan.

Paghahambing ng dalawang approach:

Mga halimbawa ng implementasyon sa Kotlin

Tingnan natin ang buong implementasyon ng Conditional GET sa Kotlin gamit ang OkHttp at Room para sa pag-iimbak ng ETag. Ang application ng listahan ng mga gawain ay naglo-load ng mga gawain mula sa server at gumagamit ng kondisyonal na mga kahilingan upang mabawasan ang trapiko. Ang mga ETag ay iniimbak sa lokal na database upang mapanatili sa pagitan ng mga session.

Repository na may Conditional GET sa Kotlin:

class TaskRepository(
    private val api: TaskApi,
    private val etagDao: EtagDao
) {
    suspend fun getTasks(): List<Task> {
        val savedEtag = etagDao.getEtag("tasks")

        val response = api.fetchTasks(
            ifNoneMatch = savedEtag
        )

        return when (response.code()) {
            304 -> taskDao.getAll() // mula sa lokal na cache
            200 -> {
                response.header("ETag")?.let {
                    etagDao.saveEtag("tasks", it)
                }
                val tasks = response.body() ?: emptyList()
                taskDao.replaceAll(tasks)
                tasks
            }
            else -> throw Exception(
                "Sync failed: ${response.code()}")
        }
    }
}

TaskRepository ay sinusuri ang code ng tugon: ang 304 ay nangangahulugang walang pagbabago, at ang data ay ibinabalik mula sa lokal na cache ng Room. Sa 200, ang bagong ETag ay ini-save at ang mga gawain ay ina-update sa lokal na database. Ang pattern na ito ay pamantayan para sa mga mobile application na nag-ssync sa pamamagitan ng REST API.

Aplikasyon ng Conditional GET sa mobile development

Ang Conditional GET ay malawakang ginagamit sa mga mobile application para i-optimize ang pag-sync ng data. Mga pangunahing senaryo: pag-load ng news feed (Twitter, Instagram ay pana-panahong nagtatanong sa API gamit ang If-None-Match), pag-update ng profile ng user, pag-load ng listahan ng notifications, at pag-sync ng mga gawain. Sa bawat kaso, maaaring suriin ng application ang pagiging bago ng data nang hindi muling naglo-load.

Para sa mga offline-first application, ang Conditional GET ay nagsisilbing unang yugto ng pag-sync. Ang application ay unang nagpapadala ng kondisyonal na GET na mga kahilingan para sa lahat ng resource na lokal na binago mula noong huling pag-sync. Ang mga resource na may 304 ay hindi nangangailangan ng pag-load. Pagkatapos nito, ang application ay nagpapadala ng PUT/POST para sa mga lokal na pagbabago. Ang ganitong dalawang-yugtong approach ay nagsisiguro ng minimal na konsumo ng data.

Sa kombinasyon sa Conflict Resolution, pinapayagan ng Conditional GET ang mahusay na pagtuklas ng mga conflict. Kung ang client ay nakatanggap ng 200 na may bagong data (nagbago ang resource), ngunit ang client ay may hindi naipadalang lokal na pagbabago — may conflict na nare-record. Maaaring ilapat ng client ang LWW (nawawala ang lokal na pagbabago) o magpatakbo ng Merge Strategy para pagsamahin ang lokal at malayuang pagbabago. Ayon sa Meta Engineering Blog (2025), ang pagpapatupad ng Conditional GET sa Messenger ay nagbawas ng average na konsumo ng data para sa pag-sync ng 73%.