OkHttp — apa itu, fitur dan arsitektur klien HTTP

Apa itu OkHttp?

OkHttp adalah klien HTTP yang efisien untuk Java, Android, dan Kotlin, dikembangkan oleh Square. Pustaka ini menyediakan API tingkat rendah untuk melakukan permintaan HTTP dengan dukungan HTTP/2, SPDY, WebSocket, dan pemulihan koneksi otomatis saat terjadi kegagalan jaringan.

OkHttp muncul pada tahun 2013 sebagai jawaban atas kebutuhan akan klien HTTP yang andal yang dapat memecahkan masalah HttpURLConnection — kurangnya pool koneksi, dukungan HTTP/2 yang lemah, dan API yang tidak nyaman. Pada tahun 2025, OkHttp digunakan di tingkat sistem Android API: OkHttp tertanam dalam implementasi HttpURLConnection sejak Android 4.4 (API 19).

Menurut Google I/O 2024, OkHttp memproses lebih dari 70% dari semua permintaan HTTP di ekosistem Android. Ini dimungkinkan karena OkHttp adalah lapisan transport untuk Retrofit, Apollo GraphQL, Firebase, dan banyak pustaka lainnya. Pengembang mendapatkan fungsionalitas OkHttp secara otomatis, tanpa menghubungkannya secara eksplisit.

Bagaimana OkHttp bekerja

Arsitektur OkHttp dibangun di atas rantai interceptor (Interceptor chain). Setiap permintaan melewati serangkaian interceptor yang dapat memodifikasi Request, Response, atau menghentikan eksekusi. Arsitektur ini mengingatkan pada pola Chain of Responsibility dan memungkinkan perluasan fungsionalitas secara fleksibel.

Ketika aplikasi mengirim permintaan, OkHttp melakukan langkah-langkah berikut: menyelesaikan DNS, memilih koneksi dari pool (atau membuat yang baru), membuka jabat tangan TLS (jika HTTPS), mengirim permintaan HTTP, menerima respons, dan mengembalikannya ke aplikasi. RealCall adalah kelas internal yang mengelola siklus hidup lengkap permintaan dari pembuatan hingga penyelesaian.

OkHttp secara otomatis menangani pengalihan (302, 301), mengulangi permintaan saat terjadi kegagalan jaringan (retry), mengikuti protokol keep-alive, dan mendukung kompresi gzip transparan. Pengembang tidak perlu menulis kode untuk operasi ini — OkHttp melakukannya secara otomatis berdasarkan header server.

Dukungan HTTP/2 dan multipleksing

HTTP/2 memungkinkan pengiriman beberapa permintaan melalui satu koneksi TCP secara bersamaan, tanpa pemblokiran (head-of-line blocking, yang merupakan ciri HTTP/1.1). OkHttp secara otomatis menggunakan HTTP/2 jika server mendukung protokol ini dan beralih secara transparan ke HTTP/1.1 saat diperlukan.

Multipleksing HTTP/2 sangat penting untuk aplikasi seluler, di mana latensi pembuatan koneksi (TCP + TLS) bisa mencapai 100–300 ms. Alih-alih 10 koneksi berurutan, OkHttp menggunakan satu koneksi, mengurangi latensi total sebesar 40–60% pada perangkat Android tipikal dengan koneksi tidak stabil.

Interceptor OkHttp: Interceptor dan NetworkInterceptor

Interceptor adalah antarmuka dengan satu metode intercept(Chain) yang menerima Request, melakukan tindakan, dan mengembalikan Response. Interceptor terdiri dari dua jenis: interceptor aplikasi (ditambahkan melalui addInterceptor) dan interceptor jaringan (addNetworkInterceptor).

Interceptor aplikasi diaktifkan sebelum permintaan HTTP dibentuk — mereka melihat Request asli dan Response akhir setelah semua transformasi. Interceptor jaringan diaktifkan di tingkat jaringan: mereka melihat permintaan setelah kompresi gzip, penambahan header Content-Length, pengalihan, dan percobaan ulang. Interceptor jaringan tidak dipanggil jika respons diperoleh dari cache.

Penerapan interceptor dalam praktik

Dalam praktiknya, interceptor OkHttp menyelesaikan tiga tugas utama: otorisasi (menambahkan header Authorization), pencatatan log (HttpLoggingInterceptor untuk debugging), dan percobaan ulang (pengulangan otomatis permintaan saat terjadi kegagalan jaringan). Dengan menggabungkan beberapa interceptor, pipeline pemrosesan permintaan yang lengkap dapat dibangun tanpa duplikasi kode di setiap panggilan HTTP aplikasi.

Urutan penambahan interceptor penting: Interceptor yang ditambahkan pertama dieksekusi pertama saat masuk dan terakhir saat keluar. Untuk NetworkInterceptor, urutan ditentukan oleh tumpukan jaringan. Urutan yang direkomendasikan: AuthInterceptor (menambahkan token), LoggingInterceptor (mencatat permintaan), RetryInterceptor (mengulangi saat kegagalan).

Pencatatan log melalui HttpLoggingInterceptor

Untuk debugging permintaan jaringan, digunakan HttpLoggingInterceptor — interceptor siap pakai dari Square. Ini mencatat metode, URL, header, dan body permintaan serta respons. Tingkat pencatatan: BASIC (metode + URL + kode), HEADERS (dengan header), dan BODY (permintaan dan respons lengkap). BODY berguna selama pengembangan, tetapi di produksi dinonaktifkan karena alasan keamanan dan kinerja.

Contoh kode OkHttp di Kotlin

Mari kita lihat permintaan GET dasar melalui OkHttp. Pertama, OkHttpClient dibuat — objek berat yang dibuat sekali dan digunakan kembali. Kemudian Request dengan URL dibentuk, dan permintaan dieksekusi secara sinkron melalui execute atau asinkron melalui enqueue.

val client = OkHttpClient.Builder()
    .connectTimeout(15, TimeUnit.SECONDS)
    .readTimeout(15, TimeUnit.SECONDS)
    .build()

val request = Request.Builder()
    .url("https://api.github.com/users/octocat")
    .header("Accept", "application/vnd.github.v3+json")
    .build()

val response = client.newCall(request).execute()
println(response.body()?.string())

Untuk eksekusi asinkron digunakan metode enqueue, yang menerima Callback. OkHttp mengeksekusi permintaan di thread latar belakang dan mengembalikan hasilnya di callback pada thread yang sama. Untuk beralih ke thread utama Android, gunakan Handler atau coroutine.

client.newCall(request).enqueue(object : Callback {
    override fun onFailure(
        call: Call, e: IOException
    ) {
        println("Permintaan gagal: ${e.message}")
    }

    override fun onResponse(
        call: Call, response: Response
    ) {
        println(response.body()?.string())
    }
})

Menambahkan interceptor untuk otorisasi

Interceptor kustom menambahkan token Bearer ke setiap permintaan. Interceptor memeriksa keberadaan header Authorization, dan jika token belum diatur, menambahkannya dari penyimpanan. Pada respons 401, interceptor dapat memperbarui token melalui Authenticator.

class AuthInterceptor(
    private val tokenProvider: () -> String?
) : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val originalRequest = chain.request()
        val token = tokenProvider.invoke()
        val request = originalRequest.newBuilder()
            .header("Authorization", "Bearer $token")
            .build()
        return chain.proceed(request)
    }
}

Pool koneksi dan caching OkHttp

Pool koneksi (ConnectionPool) — optimasi utama OkHttp, yang memungkinkan penggunaan ulang koneksi TCP untuk beberapa permintaan. Alih-alih membuat soket baru untuk setiap permintaan, OkHttp menyimpan hingga 5 koneksi tidak aktif (secara default) selama 5 menit, yang mengurangi latensi sebesar 30–70% untuk permintaan berulang ke host yang sama.

Caching respons diimplementasikan melalui kelas Cache. Untuk mengaktifkan cache, cukup tentukan direktori dan ukuran maksimum di OkHttpClient.Builder. OkHttp secara otomatis menyimpan cache respons GET sesuai dengan header Cache-Control, Expires, dan ETag, mengembalikan data yang di-cache tanpa permintaan jaringan jika belum kedaluwarsa.

val cacheDir = File(context.cacheDir, "http-cache")
val cache = Cache(cacheDir, 10L * 1024 * 1024)

val client = OkHttpClient.Builder()
    .cache(cache)
    .connectionPool(ConnectionPool(5, 5, TimeUnit.MINUTES))
    .build()

Konfigurasi pool dan cache yang tepat sangat penting untuk aplikasi dengan permintaan yang sering — feed berita, obrolan, pembaruan data. Tanpa pool, setiap koneksi TCP memerlukan jabat tangan tiga arah (SYN, SYN-ACK, ACK) dan potensial jabat tangan TLS (2–3 round-trip), yang menambah 100–500 ms ke setiap permintaan.

OkHttp juga mendukung WebSocket melalui kelas RealWebSocket. Koneksi WebSocket dibuat melalui jabat tangan HTTP (101 Switching Protocols) dan kemudian beralih ke protokol dua arah. OkHttp secara otomatis mengirim frame ping untuk menjaga koneksi tetap hidup dan menyambung kembali saat terputus. WebSocket dari OkHttp kompatibel dengan endpoint standar seperti wss://echo.websocket.org.

Kesalahan umum saat bekerja dengan OkHttp

Membuat OkHttpClient untuk setiap permintaan — kesalahan paling umum. OkHttpClient berisi pool koneksi, cache, dan pool thread. Membuat instance baru untuk setiap permintaan tidak hanya membuang memori, tetapi juga menghilangkan keuntungan dari penggunaan ulang koneksi. OkHttpClient harus menjadi singleton melalui kontainer DI.

Mengabaikan penutupan Response.body() menyebabkan kebocoran sumber daya. ResponseBody berisi InputStream yang harus ditutup setelah dibaca. Jika menggunakan body().string() atau body().bytes(), OkHttp menutup aliran secara otomatis, tetapi saat membaca body().byteStream() atau body().charStream(), diperlukan panggilan close() eksplisit di blok finally.

Tidak adanya penanganan Timeout — masalah lainnya. Secara default, OkHttp tidak memiliki batas waktu (connectTimeout = 10 detik, readTimeout = 10 detik, writeTimeout = 10 detik). Untuk aplikasi seluler dengan koneksi tidak stabil, disarankan untuk mengatur connectTimeout 15–30 detik dan readTimeout 15–30 detik, jika tidak pengguna akan menunggu terlalu lama saat sinyal lemah.