Conditional GET: шта је, механизам условног захтева

Шта је Conditional GET у HTTP-у?

Conditional GET — је GET захтев који садржи једно или више условних заглавља, на основу којих сервер одлучује да ли да врати потпун одговор или само статус 304 Not Modified. Основни циљ је избегавање преноса тела одговора, ако се ресурс није променио од последњег захтева. Ово је фундаментални механизам HTTP кеширања, дефинисан у спецификацији RFC 7232.

За мобилне апликације, Conditional GET је један од најефикаснијих начина оптимизације мрежног саобраћаја. Типичан сценарио: при отварању апликације, клијент шаље серију условних GET захтева за учитавање феда, профила и подешавања. Ако се подаци нису променили, апликација добија 304 и користи локалну копију. Ово траје милисекунде уместо секунди и не троши мобилни саобраћај.

Према Google Web Fundamentals (2025), имплементација условних GET захтева у мобилној апликацији смањује просечно време учитавања за 40–60% за поновне посете и смањује потрошњу саобраћаја за 70–90% за странице са ретким ажурирањима. Ефекат је посебно приметан на спорим везама (3G, Edge), где је сваки бајт битан.

Како ради условни GET захтев

Процес се састоји од три корака. Први — клијент шаље обичан GET захтев, сервер враћа ресурс заједно са заглављима кеширања (ETag, Last-Modified). Други — клијент чува ресурс и његове валидаторе локално. Трећи — при поновном захтеву, клијент шаље GET са If-None-Match (за ETag) и/или If-Modified-Since (за Last-Modified). Сервер проверава валидаторе и одговара 304 ако се ресурс није променио, или 200 са новим подацима.

Сервер користи приоритет ETag-а над Last-Modified када су оба заглавља присутна. Ово је зато што ETag обезбеђује прецизнију валидацију — хеш садржаја се мења при било којој промени, док Last-Modified има резолуцију од једне секунде. Ако се ETag поклапа, сервер одмах враћа 304, не проверавајући Last-Modified.

Пример пуног циклуса Conditional GET-а у секвенци захтева:

// Корак 1: Први захтев — добијте податке и ETag
GET /api/profile
Response: 200 OK
ETag: "33a64df551425fcc55e"
Body: { "name": "Alice" }

// Корак 2: Поновите захтев — са If-None-Match
GET /api/profile
If-None-Match: "33a64df551425fcc55e"
Response: 304 Not Modified
// Тело одговора недостаје — користите локалну копију

У другом захтеву, сервер упоређује ETag из If-None-Match са тренутним хешом ресурса. При поклапању, враћа се 304 без тела — клијент наставља да користи кеширане податке. Ово је суштина Conditional GET-а: минимум саобраћаја уз максималну актуелност података.

Conditional GET против обичног GET-а

Обичан GET захтев увек враћа пун одговор 200 OK са телом. Чак и ако се ресурс није променио, сервер поново преноси све податке. Ово је прихватљиво за мале ресурсе или ретке захтеве, али за мобилне апликације са стотинама захтева при сваком покретању, такав приступ доводи до прекомерне потрошње саобраћаја и батерије.

Conditional GET додаје додатни трошак у виду заглавља (обично 50–200 бајтова по захтеву), али штеди килобајте и мегабајте при одговору 304. Што је ресурс већи, то је условни захтев исплативији. За слике, листе података и JSON документе величине од 10 KB, Conditional GET се исплаћује од првог поновног захтева.

Упоредне карактеристике два приступа:

Примери имплементације у Kotlin-у

Размотримо потпуну имплементацију Conditional GET-а у Kotlin-у коришћењем OkHttp и Room за чување ETag-а. Апликација листе задатака учитава задатке са сервера и користи условне захтеве за минимизацију саобраћаја. ETag-ови се чувају у локалној бази података ради очувања између сесија.

Репозиторијум са Conditional GET-ом у 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() // из локалног кеша
            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 проверава код одговора: 304 значи да нема промена, и подаци се враћају из локалног кеша Room-а. При 200, нови ETag се чува, а задаци се ажурирају у локалној бази. Овај образац је стандард за мобилне апликације које се синхронизују путем REST API-ја.

Примена Conditional GET-а у мобилном развоју

Conditional GET се широко користи у мобилним апликацијама за оптимизацију синхронизације података. Главни сценарији: учитавање феда вести (Twitter, Instagram периодично опитују API са If-None-Match), ажурирање профила корисника, учитавање листе обавештења и синхронизација задатака. У сваком случају, апликација може да провери актуелност података без поновног учитавања.

За офлајн-first апликације, Conditional GET служи као прва фаза синхронизације. Апликација прво шаље условне GET захтеве за све ресурсе који су локално измењени од последње синхронизације. Ресурси са 304 не захтевају учитавање. Након тога, апликација шаље PUT/POST за локалне промене. Овакав двофазни приступ обезбеђује минималну потрошњу саобраћаја.

У комбинацији са Conflict Resolution, Conditional GET омогућава ефикасно откривање конфликата. Ако је клијент добио 200 са новим подацима (ресурс се променио), али клијент има непослате локалне промене — региструје се конфликт. Клијент може да примени LWW (локалне промене се губе) или да покрене Merge Strategy за спајање локалних и удаљених промена. Према Meta Engineering Blog (2025), имплементација Conditional GET-а у Messenger-у смањила је просечну потрошњу саобраћаја на синхронизацију за 73%.