Conditional GET: apa itu, mekanisme permintaan bersyarat

Apa itu Conditional GET dalam HTTP?

Conditional GET — adalah permintaan GET yang berisi satu atau lebih header bersyarat, berdasarkan mana server memutuskan apakah akan mengembalikan respons lengkap atau hanya status 304 Not Modified. Tujuan utamanya adalah menghindari pengiriman badan respons jika sumber daya tidak berubah sejak permintaan terakhir. Ini adalah mekanisme fundamental caching HTTP, yang didefinisikan dalam spesifikasi RFC 7232.

Untuk aplikasi mobile, Conditional GET adalah salah satu cara paling efektif untuk mengoptimalkan lalu lintas jaringan. Skenario tipikal: saat membuka aplikasi, klien mengirim serangkaian permintaan GET bersyarat untuk memuat feed, profil, dan pengaturan. Jika data tidak berubah, aplikasi menerima 304 dan menggunakan salinan lokal. Ini membutuhkan milidetik, bukan detik, dan tidak menghabiskan bandwidth seluler.

Menurut Google Web Fundamentals (2025), implementasi permintaan GET bersyarat dalam aplikasi mobile mengurangi waktu muat rata-rata sebesar 40–60% untuk kunjungan berulang dan menurunkan konsumsi bandwidth sebesar 70–90% untuk halaman dengan pembaruan jarang. Efeknya terutama terlihat pada koneksi lambat (3G, Edge), di mana setiap byte berarti.

Bagaimana cara kerja permintaan GET bersyarat

Prosesnya terdiri dari tiga langkah. Pertama — klien mengirim permintaan GET biasa, server mengembalikan sumber daya bersama dengan header caching (ETag, Last-Modified). Kedua — klien menyimpan sumber daya dan validatornya secara lokal. Ketiga — pada permintaan berulang, klien mengirim GET dengan If-None-Match (untuk ETag) dan/atau If-Modified-Since (untuk Last-Modified). Server memeriksa validator dan merespons 304 jika sumber daya tidak berubah, atau 200 dengan data baru.

Server menggunakan prioritas ETag di atas Last-Modified ketika kedua header ada. Ini karena ETag memberikan validasi yang lebih akurat — hash konten berubah pada setiap perubahan, sedangkan Last-Modified memiliki resolusi satu detik. Jika ETag cocok, server segera mengembalikan 304 tanpa memeriksa Last-Modified.

Contoh siklus lengkap Conditional GET dalam urutan permintaan:

// Langkah 1: Permintaan pertama — dapatkan data dan ETag
GET /api/profile
Response: 200 OK
ETag: "33a64df551425fcc55e"
Body: { "name": "Alice" }

// Langkah 2: Ulangi permintaan — dengan If-None-Match
GET /api/profile
If-None-Match: "33a64df551425fcc55e"
Response: 304 Not Modified
// Badan respons tidak ada — gunakan salinan lokal

Dalam permintaan kedua, server membandingkan ETag dari If-None-Match dengan hash sumber daya saat ini. Jika cocok, 304 dikembalikan tanpa badan — klien terus menggunakan data yang di-cache. Inilah esensi Conditional GET: lalu lintas minimal dengan keaktualan data maksimal.

Conditional GET vs GET biasa

Permintaan GET biasa selalu mengembalikan respons lengkap 200 OK dengan badan. Bahkan jika sumber daya tidak berubah, server mengirim semua data lagi. Ini dapat diterima untuk sumber daya kecil atau permintaan jarang, tetapi untuk aplikasi mobile dengan ratusan permintaan setiap kali dijalankan, pendekatan seperti itu menyebabkan konsumsi bandwidth dan baterai yang berlebihan.

Conditional GET menambahkan overhead berupa header (biasanya 50–200 byte per permintaan), tetapi menghemat kilobyte dan megabyte pada respons 304. Semakin besar sumber daya, semakin menguntungkan permintaan bersyarat. Untuk gambar, daftar data, dan dokumen JSON berukuran 10 KB ke atas, Conditional GET terbayar sejak permintaan berulang pertama.

Perbandingan kedua pendekatan:

Contoh implementasi di Kotlin

Mari kita lihat implementasi lengkap Conditional GET di Kotlin menggunakan OkHttp dan Room untuk menyimpan ETag. Aplikasi daftar tugas memuat tugas dari server dan menggunakan permintaan bersyarat untuk meminimalkan lalu lintas. ETag disimpan di basis data lokal untuk dipertahankan antar sesi.

Repositori dengan Conditional GET di 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() // dari cache lokal
            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 memeriksa kode respons: 304 berarti tidak ada perubahan, dan data dikembalikan dari cache lokal Room. Pada 200, ETag baru disimpan dan tugas diperbarui di basis data lokal. Pola ini adalah standar untuk aplikasi mobile yang sinkron melalui REST API.

Penerapan Conditional GET dalam pengembangan mobile

Conditional GET banyak digunakan dalam aplikasi mobile untuk mengoptimalkan sinkronisasi data. Skenario utama: memuat feed berita (Twitter, Instagram secara berkala menanyai API dengan If-None-Match), memperbarui profil pengguna, memuat daftar notifikasi, dan sinkronisasi tugas. Dalam setiap kasus, aplikasi dapat memeriksa keaktualan data tanpa memuat ulang.

Untuk aplikasi offline-first, Conditional GET berfungsi sebagai tahap pertama sinkronisasi. Aplikasi pertama-tama mengirim permintaan GET bersyarat untuk semua sumber daya yang telah dimodifikasi secara lokal sejak sinkronisasi terakhir. Sumber daya dengan 304 tidak memerlukan pemuatan. Setelah itu, aplikasi mengirim PUT/POST untuk perubahan lokal. Pendekatan dua fase seperti ini memastikan konsumsi bandwidth minimal.

Dalam kombinasi dengan Conflict Resolution, Conditional GET memungkinkan deteksi konflik yang efisien. Jika klien menerima 200 dengan data baru (sumber daya berubah), tetapi klien memiliki perubahan lokal yang belum dikirim — konflik dicatat. Klien dapat menerapkan LWW (perubahan lokal hilang) atau menjalankan Merge Strategy untuk menggabungkan perubahan lokal dan jarak jauh. Menurut Meta Engineering Blog (2025), implementasi Conditional GET di Messenger mengurangi konsumsi bandwidth rata-rata untuk sinkronisasi sebesar 73%.