Interceptor — wat het is, typen interceptors in OkHttp en Alamofire

Wat is Interceptor?

Interceptor — een softwarecomponent die in de HTTP-client wordt geïnjecteerd om verzoeken vóór verzending naar de server en antwoorden vóór overdracht naar de app te onderscheppen en wijzigen. In mobiele ontwikkeling lossen interceptors cross-cutting taken op: automatisch toevoegen van authenticatietokens, verkeersloggen met tijdsmetingen, herpogingen bij tijdelijke netwerkfouten, compressie en ontsleuteling van gegevens onderweg. De Interceptor-architectuur is gebaseerd op het Chain of Responsibility-patroon — elke interceptor kan het verzoek wijzigen, uitvoeren of de keten onderbreken door een aangepast antwoord terug te sturen.

Hoe de interceptorketen werkt

In OkHttp vormen interceptors een keten (chain). Elke Interceptor ontvangt een Chain-object met het originele verzoek en roept chain.proceed(request) aan om de controle door te geven aan de volgende interceptor. Na ontvangst van het antwoord kan de interceptor de Response analyseren, wijzigen, het verzoek bij fouten herhalen of een aangepast antwoord voor caching retourneren. De volgorde van toevoegen van interceptors in OkHttpClient.Builder bepaalt de uitvoervolgorde: de eerst toegevoegde wordt als eerste uitgevoerd bij verzenden en als laatste bij ontvangen.

Interceptor in OkHttp: Application en Network

OkHttp verdeelt interceptors in twee typen. Application Interceptor (addInterceptor) wordt uitgevoerd tussen de applicatiecode en OkHttp: één chain.proceed()-aanroep — één verzoek naar de server, ongeacht omleidingen. Network Interceptor (addNetworkInterceptor) wordt binnen OkHttp uitgevoerd na het vormen van headers en verbinding — geactiveerd bij elke omleiding, herpoging of authenticatie. Dit verschil is cruciaal voor de juiste keuze van het interceptortype voor een specifieke taak.

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

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

LoggingInterceptor — een Application Interceptor die de methode, URL, antwoordcode en uitvoertijd logt. Toevoegen via addInterceptor() garandeert één log per gebruikersverzoek zonder duplicatie bij omleidingen. CacheInterceptor is toegevoegd als Network Interceptor om de Cache-Control-headers van de server in aanmerking te nemen, die alleen binnen OkHttp zichtbaar zijn na het vormen van het HTTP-verzoek.

Verschil tussen typen in de praktijk

Wanneer de app een verzoek indient, kan de server reageren met een 302- of 301-omleiding. Application Interceptor ziet alleen het uiteindelijke antwoord na alle omleidingen — het weet niet hoeveel tussenliggende verzoeken zijn gedaan. Network Interceptor ziet elk verzoek en antwoord, inclusief tussenliggende. Volgens Square (2026) ziet Network Interceptor ook gegevens die op verbindingsniveau zijn gecomprimeerd (gzip), terwijl Application Interceptor het al gedecomprimeerde antwoord ontvangt. Gebruik Network Interceptor voor het tellen van het werkelijke aantal netwerkoproepen.

Alamofire RequestInterceptor

Alamofire biedt het RequestInterceptor-protocol dat twee protocollen combineert: RequestAdapter voor het wijzigen van het verzoek voor verzending en RequestRetrier voor herpogingen bij fouten. Deze scheiding maakt flexibele combinatie van aanpassing (toevoegen van headers, tokens) met herpogingsbeleid (exponentiële vertraging, limiet pogingen, controle fouttype) mogelijk. RequestInterceptor wordt geïmplementeerd door één structuur of klasse die beide protocollen implementeert.

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 in Swift voegt Bearer-token toe via adapt en herhaalt automatisch het verzoek bij URLError (netwerkverlies, timeout) via retry met een vertraging van 1 seconde. Scheiding van aanpassing en herpogingen maakt onafhankelijk testen mogelijk — er kan een unittest worden geschreven voor aanpassing zonder de retry-logica te beïnvloeden. Volgens Alamofire (2026) is RequestInterceptor de standaardmanier voor gecentraliseerd authenticatiebeheer in iOS-projecten.

Gebruiksscenario's voor interceptors

Loggen — het meest voorkomende scenario. Interceptor registreert URL, methode, headers, verzoek- en antwoordbody, uitvoertijd. In debug-builds vervangt dit Charles Proxy en Wireshark, in release helpt het foutrapporten met verzoekcontext. Voor OkHttp wordt HttpLoggingInterceptor uit de logging-interceptor-bibliotheek gebruikt met niveaus NONE, BASIC, HEADERS en BODY. BODY-niveau logt volledige verzoek- en antwoordbody's — alleen gebruiken in debug.

Authenticatie en Refresh Token

Wanneer het access token verloopt, onderschept Interceptor het 401-antwoord, roept de refresh token API aan en herhaalt het originele verzoek met het nieuwe token. In OkHttp wordt dit geïmplementeerd via Authenticator of een aangepaste Interceptor met response.code-controle. Authenticator heeft alleen toegang tot de antwoordheaders, Interceptor — tot de volledige body. In Alamofire — via RequestRetrier die .retry retourneert na tokenvernieuwing. Volgens OWASP (2026) vermindert automatische tokenvernieuwing via Interceptor het risico op lekkage van inloggegevens.

Toevoegen van algemene headers

Content-Type, Accept-Language, User-Agent, Device-ID — headers die in elk verzoek nodig zijn. Interceptor voegt ze gecentraliseerd toe, zonder duplicatie in elke API-methode. User-Agent wordt eenmalig gevormd bij het starten van de app: „AppName/1.0 (Android 14; Pixel 8)“. Accept-Language wordt overgenomen uit de systeemtaal van het apparaat. Volgens Alamofire (2026) vermindert gecentraliseerd headerbeheer via Interceptor het aantal fouten door onjuiste headers met 30%.

Best practices en ketenvolgorde

De volgorde van Interceptor toevoegen in OkHttp bepaalt het gedrag van de hele keten. De eerst toegevoegde interceptor wordt als eerste uitgevoerd bij het verzenden van het verzoek en als laatste bij het ontvangen van het antwoord. Voor loggen voegt u Interceptor als eerste toe — deze ziet het uiteindelijke verzoek met alle wijzigingen van andere interceptors. Voor compressie — als laatste, zodat compressie wordt toegepast op de uiteindelijke gegevens. Voor authenticatie — vóór herpoging, zodat het token wordt vernieuwd vóór de herpoging.

Aanbevelingen voor productie-builds

Schakel in release-builds loggen uit via BuildConfig.DEBUG of dependency-injectie. Gebruik addNetworkInterceptor voor caching — Network Interceptor ziet de Cache-Control-headers van de server en interpreteert het cachebeleid correct. Voor authenticatie gebruikt u addInterceptor (Application) — dit voorkomt hernieuwde onderschepping bij omleidingen naar externe domeinen waar autorisatieheaders niet mogen worden verzonden. Test elke Interceptor geïsoleerd met MockWebServer uit okhttp-testing-support — deze onderschept verzoeken en retourneert vooraf voorbereide antwoorden, waarmee de interceptlogica kan worden gecontroleerd zonder echte server.

Interceptor-prestaties

Elke Interceptor voegt een kleine vertraging toe aan de verzoekstijd. In een typische keten van 3–4 interceptors (loggen, authenticatie, compressie, caching) bedraagt de overhead minder dan 5 milliseconden per verzoek. Problemen ontstaan wanneer Interceptor blokkerende bewerkingen uitvoert: synchrone refresh token API-aanroep, schrijven van grote logs naar bestand of codering van verzoekbody. Al deze bewerkingen moeten asynchroon zijn of op een achtergrondthread worden uitgevoerd. Volgens Square (2026) voert OkHttp Interceptor uit in de Dispatcher-threadpool — blokkering van één interceptor vertraagt de hele keten.

• Volgorde is belangrijk — loggen eerst, authenticatie vóór herpoging, compressie als laatste
• Debug vs Release — HttpLoggingInterceptor alleen in debug-builds
• Isolatie — elke Interceptor lost één taak op (Single Responsibility)
• Asynchroniteit — Interceptor wordt uitgevoerd op de achtergrondthread van OkHttp, zonder UI te blokkeren