Interceptor — ano ito, mga uri ng interceptor ng OkHttp at Alamofire

Ano ang Interceptor?

Interceptor — bahagi ng software na idinadagdag sa HTTP client para humarang at magbago ng mga request bago ipadala sa server at mga response bago ipasa sa app. Sa mobile development, nilulutas ng mga interceptor ang mga cross-cutting na gawain: awtomatikong pagdagdag ng authentication tokens, pag-log ng trapiko na may pagsukat ng oras, muling pagsubok sa pansamantalang network errors, compression at decryption ng data sa real-time. Ang arkitektura ng Interceptor ay batay sa pattern na Chain of Responsibility — bawat interceptor ay maaaring magbago ng request, isagawa ito, o putulin ang chain sa pamamagitan ng pagbalik ng custom na response.

Paano gumagana ang chain ng mga interceptor

Sa OkHttp, ang mga interceptor ay bumubuo ng chain. Bawat Interceptor ay tumatanggap ng Chain object na may orihinal na request at tumatawag ng chain.proceed(request) para ipasa ang kontrol sa susunod na interceptor. Pagkatanggap ng response, maaaring suriin ng interceptor ang Response, baguhin ito, ulitin ang request sa error, o magbalik ng custom na response para sa caching. Ang pagkakasunod-sunod ng pagdagdag ng mga interceptor sa OkHttpClient.Builder ay tumutukoy sa pagkakasunod ng execution: ang unang idinagdag ay unang isinasagawa sa pagpapadala at huli sa pagtanggap.

Interceptor sa OkHttp: Application at Network

OkHttp ay hinahati ang mga interceptor sa dalawang uri. Application Interceptor (addInterceptor) ay isinasagawa sa pagitan ng code ng app at OkHttp: isang tawag sa chain.proceed() — isang request sa server, anuman ang mga redirect. Network Interceptor (addNetworkInterceptor) ay isinasagawa sa loob ng OkHttp pagkatapos ng pagbuo ng mga header at koneksyon — na-trigger sa bawat redirect, muling pagsubok, o authentication. Ang pagkakaibang ito ay kritikal para sa tamang pagpili ng uri ng interceptor para sa isang partikular na gawain.

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} sa loob ng ${duration}ms")
        return response
    }
}

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

LoggingInterceptor — Application Interceptor na nagla-log ng method, URL, response code, at oras ng execution. Ang pagdagdag sa pamamagitan ng addInterceptor() ay ginagarantiyahan ang isang log bawat user request nang walang pagdoble sa mga redirect. CacheInterceptor ay idinagdag bilang Network Interceptor upang isaalang-alang ang Cache-Control header ng server, na makikita lamang sa loob ng OkHttp pagkatapos ng pagbuo ng HTTP request.

Pagkakaiba sa pagitan ng mga uri sa praktika

Kapag ang app ay gumawa ng request, ang server ay maaaring tumugon ng 302 o 301 redirect. Application Interceptor ay makikita lamang ang huling response pagkatapos ng lahat ng redirect — hindi nito alam kung ilang intermediate request ang ginawa. Network Interceptor ay makikita ang bawat request at response, kasama ang mga intermediate. Ayon sa datos ng Square (2026), nakikita rin ng Network Interceptor ang data na na-compress sa antas ng koneksyon (gzip), samantalang ang Application Interceptor ay tumatanggap ng na-decompress nang response. Para sa pagbilang ng aktwal na bilang ng network calls, gamitin ang Network Interceptor.

Alamofire RequestInterceptor

Alamofire ay nagbibigay ng RequestInterceptor protocol na pinagsasama ang dalawang protocol: RequestAdapter para baguhin ang request bago ipadala at RequestRetrier para sa muling pagsubok sa mga error. Ang paghihiwalay na ito ay nagbibigay-daan sa flexible na kombinasyon ng adaptasyon (pagdagdag ng headers, tokens) na may patakaran ng muling pagsubok (exponential delay, limit ng pagsubok, pagsusuri ng uri ng error). Ang RequestInterceptor ay ipinapatupad ng isang structure o class na nagpapatupad ng parehong protocol.

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 sa Swift ay nagdadagdag ng Bearer token sa pamamagitan ng adapt at awtomatikong inuulit ang request sa URLError (pagkawala ng network, timeout) sa pamamagitan ng retry na may 1 segundong delay. Ang paghihiwalay ng adaptasyon at muling pagsubok ay nagbibigay-daan sa independiyenteng pag-test — maaaring sumulat ng unit test para sa adaptasyon nang hindi naaapektuhan ang retry logic. Ayon sa datos ng Alamofire (2026), ang RequestInterceptor ay ang pamantayang paraan ng sentralisadong pamamahala ng authentication sa mga iOS project.

Mga Sitwasyon ng Paggamit ng Interceptor

Pag-log — pinakakaraniwang sitwasyon. Inirerekord ng Interceptor ang URL, method, headers, body ng request at response, oras ng execution. Sa debug builds, pinapalitan nito ang Charles Proxy at Wireshark, sa release — tumutulong sa mga error report na may konteksto ng request. Para sa OkHttp, gamitin ang HttpLoggingInterceptor mula sa library na logging-interceptor na may mga level na NONE, BASIC, HEADERS, at BODY. Ang BODY level ay nagla-log ng buong body ng mga request at response — gamitin lamang sa debug.

Authentication at Refresh Token

Kapag nag-expire ang access token, hinarang ng Interceptor ang 401 response, tinatawagan ang refresh token API, at inuulit ang orihinal na request gamit ang bagong token. Sa OkHttp ito ay ipinapatupad sa pamamagitan ng Authenticator o custom na Interceptor na may pagsusuri ng response.code. Ang Authenticator ay may access lamang sa mga header ng response, Interceptor — sa buong body. Sa Alamofire — sa pamamagitan ng RequestRetrier na nagbabalik ng .retry pagkatapos ng pag-refresh ng token. Ayon sa datos ng OWASP (2026), ang awtomatikong pag-refresh ng token sa pamamagitan ng Interceptor ay nagpapababa ng panganib ng pagtagas ng credentials.

Pagdagdag ng mga karaniwang header

Content-Type, Accept-Language, User-Agent, Device-ID — mga header na kinakailangan sa bawat request. Idinadagdag sila ng Interceptor nang sentralisado, walang pagdoble sa bawat API method. Ang User-Agent ay nabubuo isang beses sa pagsisimula ng app: “AppName/1.0 (Android 14; Pixel 8)”. Ang Accept-Language ay kinukuha mula sa system language ng device. Ayon sa datos ng Alamofire (2026), ang sentralisadong pamamahala ng header sa pamamagitan ng Interceptor ay nagpapababa ng bilang ng mga error sa maling header ng 30%.

Pinakamahuhusay na Kasanayan at Pagkakasunod ng Chain

Ang pagkakasunod-sunod ng pagdagdag ng Interceptor sa OkHttp ay tumutukoy sa pag-uugali ng buong chain. Ang unang idinagdag na interceptor ay unang isinasagawa sa pagpapadala ng request at huli sa pagtanggap ng response. Para sa pag-log idagdag ang Interceptor nang una — makikita nito ang huling request kasama ang lahat ng pagbabago mula sa ibang mga interceptor. Para sa compression — huli, upang mailapat ang compression sa huling data. Para sa authentication — bago ang muling pagsubok, upang ma-refresh ang token bago ang muling pagsubok.

Mga rekomendasyon para sa production builds

Sa release builds, huwag paganahin ang pag-log sa pamamagitan ng BuildConfig.DEBUG o dependency injection. Gamitin ang addNetworkInterceptor para sa caching — nakikita ng Network Interceptor ang Cache-Control header ng server at wastong binibigyang kahulugan ang patakaran sa caching. Para sa authentication, gamitin ang addInterceptor (Application) — pinipigilan nito ang muling pagharang sa mga redirect sa panlabas na domain kung saan hindi dapat ipadala ang mga header ng awtorisasyon. Subukan ang bawat Interceptor nang hiwalay gamit ang MockWebServer mula sa okhttp-testing-support — hinaharang nito ang mga request at nagbabalik ng mga inihandang response, na nagbibigay-daan sa pagsusuri ng interceptor logic nang walang tunay na server.

Pagganap ng Interceptor

Bawat Interceptor ay nagdadagdag ng maliit na pagkaantala sa oras ng request. Sa tipikal na chain ng 3–4 na interceptor (pag-log, authentication, compression, caching) ang overhead ay mas mababa sa 5 millisecond bawat request. Nagsisimula ang mga problema kapag ang Interceptor ay nagsasagawa ng mga naka-block na operasyon: synchronous refresh token API tawag, pagsulat ng malalaking log sa file, o pag-encrypt ng body ng request. Lahat ng operasyong ito ay dapat na asynchronous o isagawa sa background thread. Ayon sa datos ng Square (2026), isinasagawa ng OkHttp ang Interceptor sa Dispatcher thread pool — ang pag-block ng isang interceptor ay nagpapabagal sa buong chain.

• Mahalaga ang pagkakasunod — pag-log una, authentication bago muling pagsubok, compression huli
• Debug vs Release — HttpLoggingInterceptor lamang sa debug builds
• Pagbubukod — bawat Interceptor ay lumulutas ng isang gawain (Single Responsibility)
• Asynchronisidad — Interceptor ay isinasagawa sa background thread ng OkHttp, hindi hinaharangan ang UI