Interceptor — apa itu, jenis-jenis interceptor OkHttp dan Alamofire

Apa itu Interceptor?

Interceptor — komponen perangkat lunak yang dimasukkan ke dalam klien HTTP untuk mencegat dan memodifikasi permintaan sebelum dikirim ke server dan respons sebelum diteruskan ke aplikasi. Dalam pengembangan mobile, interceptor menyelesaikan tugas lintas sektor: penambahan token autentikasi secara otomatis, pencatatan lalu lintas dengan pengukuran waktu, percobaan ulang pada kesalahan jaringan sementara, kompresi dan dekripsi data secara langsung. Arsitektur Interceptor didasarkan pada pola Chain of Responsibility — setiap interceptor dapat memodifikasi permintaan, menjalankannya, atau memutus rantai dengan mengembalikan respons khusus.

Bagaimana rantai interceptor bekerja

Di OkHttp, interceptor membentuk rantai (chain). Setiap Interceptor menerima objek Chain dengan permintaan asli dan memanggil chain.proceed(request) untuk meneruskan kendali ke interceptor berikutnya. Setelah menerima respons, interceptor dapat menganalisis Response, memodifikasinya, mengulang permintaan saat kesalahan, atau mengembalikan respons khusus untuk caching. Urutan penambahan interceptor di OkHttpClient.Builder menentukan urutan eksekusinya: yang pertama ditambahkan dieksekusi pertama saat mengirim dan terakhir saat menerima.

Interceptor di OkHttp: Application dan Network

OkHttp membagi interceptor menjadi dua jenis. Application Interceptor (addInterceptor) dieksekusi antara kode aplikasi dan OkHttp: satu panggilan chain.proceed() — satu permintaan ke server, terlepas dari pengalihan. Network Interceptor (addNetworkInterceptor) dieksekusi di dalam OkHttp setelah pembentukan header dan koneksi — dipicu pada setiap pengalihan, percobaan ulang, atau autentikasi. Perbedaan ini sangat penting untuk memilih jenis interceptor yang tepat untuk tugas tertentu.

class LoggingInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val request = chain.request()
        Log.d("HTTP", "${request.method} ${request.url}")

        val startTime = System.currentTimeMillis()
        val response = chain.proceed(request)
        val duration = System.currentTimeMillis() - startTime

        Log.d("HTTP", "${response.code} dalam ${duration}ms")
        return response
    }
}

val client = OkHttpClient.Builder()
    .addInterceptor(LoggingInterceptor())
    .addNetworkInterceptor(CacheInterceptor())
    .build()

LoggingInterceptor — Application Interceptor yang mencatat metode, URL, kode respons, dan waktu eksekusi. Penambahan melalui addInterceptor() menjamin satu log per permintaan pengguna tanpa duplikasi pada pengalihan. CacheInterceptor ditambahkan sebagai Network Interceptor untuk memperhitungkan header Cache-Control server, yang hanya terlihat di dalam OkHttp setelah pembentukan permintaan HTTP.

Perbedaan antar jenis dalam praktik

Ketika aplikasi membuat permintaan, server dapat merespons dengan pengalihan 302 atau 301. Application Interceptor hanya melihat respons akhir setelah semua pengalihan — tidak tahu berapa banyak permintaan perantara yang dilakukan. Network Interceptor melihat setiap permintaan dan respons, termasuk yang perantara. Menurut data Square (2026), Network Interceptor juga melihat data yang dikompresi pada tingkat koneksi (gzip), sedangkan Application Interceptor menerima respons yang sudah didekompresi. Untuk menghitung jumlah panggilan jaringan yang sebenarnya, gunakan Network Interceptor.

Alamofire RequestInterceptor

Alamofire menyediakan protokol RequestInterceptor yang menggabungkan dua protokol: RequestAdapter untuk memodifikasi permintaan sebelum dikirim dan RequestRetrier untuk percobaan ulang saat kesalahan. Pemisahan ini memungkinkan kombinasi fleksibel antara adaptasi (penambahan header, token) dengan kebijakan percobaan ulang (penundaan eksponensial, batas percobaan, pemeriksaan jenis kesalahan). RequestInterceptor diimplementasikan oleh satu struktur atau kelas yang mengimplementasikan kedua protokol.

struct AuthInterceptor: RequestInterceptor {
    private let tokenProvider: TokenProvider

    func adapt(_ urlRequest: URLRequest,
                using state: Session.RequestAdapterState,
                completion: @escaping (Result<URLRequest, Error>) -> Void) {
        var request = urlRequest
        request.setValue("Bearer \(tokenProvider.token)",
                        forHTTPHeaderField: "Authorization")
        completion(.success(request))
    }

    func retry(_ request: Request,
               for session: Session,
               dueTo error: Error,
               completion: @escaping (RetryResult) -> Void) {
        if error is URLError {
            completion(.retryWithDelay(1))
        } else {
            completion(.doNotRetry)
        }
    }
}

AuthInterceptor di Swift menambahkan token Bearer melalui adapt dan secara otomatis mengulang permintaan saat URLError (kehilangan jaringan, timeout) melalui retry dengan penundaan 1 detik. Pemisahan adaptasi dan percobaan ulang memungkinkan pengujian independen — seseorang dapat menulis unit test untuk adaptasi tanpa memengaruhi logika retry. Menurut data Alamofire (2026), RequestInterceptor adalah cara standar manajemen autentikasi terpusat di proyek iOS.

Skenario Penggunaan Interceptor

Pencatatan — skenario paling umum. Interceptor mencatat URL, metode, header, body permintaan dan respons, waktu eksekusi. Di build debug, ini menggantikan Charles Proxy dan Wireshark, di release — membantu laporan kesalahan dengan konteks permintaan. Untuk OkHttp gunakan HttpLoggingInterceptor dari pustaka logging-interceptor dengan level NONE, BASIC, HEADERS, dan BODY. Level BODY mencatat body lengkap permintaan dan respons — gunakan hanya di debug.

Autentikasi dan Refresh Token

Ketika access token kedaluwarsa, Interceptor mencegat respons 401, memanggil refresh token API, dan mengulang permintaan asli dengan token baru. Di OkHttp ini diimplementasikan melalui Authenticator atau Interceptor khusus dengan pemeriksaan response.code. Authenticator hanya memiliki akses ke header respons, Interceptor — ke body lengkap. Di Alamofire — melalui RequestRetrier yang mengembalikan .retry setelah token diperbarui. Menurut data OWASP (2026), pembaruan token otomatis melalui Interceptor mengurangi risiko kebocoran kredensial.

Penambahan header umum

Content-Type, Accept-Language, User-Agent, Device-ID — header yang diperlukan di setiap permintaan. Interceptor menambahkannya secara terpusat, tanpa duplikasi di setiap metode API. User-Agent dibentuk sekali saat aplikasi dimulai: “AppName/1.0 (Android 14; Pixel 8)”. Accept-Language diambil dari bahasa sistem perangkat. Menurut data Alamofire (2026), manajemen header terpusat melalui Interceptor mengurangi jumlah kesalahan header yang salah hingga 30%.

Praktik Terbaik dan Urutan Rantai

Urutan penambahan Interceptor di OkHttp menentukan perilaku seluruh rantai. Interceptor pertama yang ditambahkan dieksekusi pertama saat mengirim permintaan dan terakhir saat menerima respons. Untuk pencatatan tambahkan Interceptor pertama — ia akan melihat permintaan akhir dengan semua modifikasi dari interceptor lain. Untuk kompresi — terakhir, agar kompresi diterapkan pada data akhir. Untuk autentikasi — sebelum percobaan ulang, agar token diperbarui sebelum percobaan ulang.

Rekomendasi untuk build production

Di build release, nonaktifkan pencatatan melalui BuildConfig.DEBUG atau injeksi ketergantungan. Gunakan addNetworkInterceptor untuk caching — Network Interceptor melihat header Cache-Control server dan menafsirkan kebijakan caching dengan benar. Untuk autentikasi terapkan addInterceptor (Application) — ini mencegah pencegat ulang pada pengalihan ke domain eksternal di mana header otorisasi tidak boleh dikirim. Uji setiap Interceptor secara terisolasi menggunakan MockWebServer dari okhttp-testing-support — ia mencegat permintaan dan mengembalikan respons yang sudah disiapkan, memungkinkan pemeriksaan logika interceptor tanpa server sungguhan.

Kinerja Interceptor

Setiap Interceptor menambahkan sedikit penundaan ke waktu permintaan. Dalam rantai tipikal 3–4 interceptor (pencatatan, autentikasi, kompresi, caching) overheadnya kurang dari 5 milidetik per permintaan. Masalah dimulai ketika Interceptor melakukan operasi pemblokiran: panggilan sinkron refresh token API, menulis log besar ke file, atau mengenkripsi body permintaan. Semua operasi ini harus asinkron atau dijalankan di thread latar belakang. Menurut data Square (2026), OkHttp menjalankan Interceptor di kumpulan thread Dispatcher — pemblokiran satu interceptor menunda seluruh rantai.

• Urutan penting — pencatatan pertama, autentikasi sebelum percobaan ulang, kompresi terakhir
• Debug vs Release — HttpLoggingInterceptor hanya di build debug
• Isolasi — setiap Interceptor menyelesaikan satu tugas (Single Responsibility)
• Asinkronisitas — Interceptor dijalankan di thread latar OkHttp, tidak memblokir UI