Interceptor — was es ist, Arten von OkHttp- und Alamofire-Interceptoren

Was ist ein Interceptor?

Interceptor ist eine Softwarekomponente, die in einen HTTP-Client eingefügt wird, um Anfragen vor dem Senden an den Server und Antworten vor dem Erreichen der Anwendung abzufangen und zu modifizieren. In der mobilen Entwicklung bewältigen Interceptoren querschnittliche Aufgaben: automatische Injektion von Authentifizierungstoken, Verkehrsprotokollierung mit Zeitmessungen, Wiederholungsversuche bei temporären Netzwerkfehlern sowie Datenkomprimierung und -entschlüsselung im laufenden Betrieb. Die Interceptor-Architektur basiert auf dem Chain of Responsibility-Muster — jeder Interceptor kann die Anfrage modifizieren, ausführen oder die Kette durch Rückgabe einer benutzerdefinierten Antwort unterbrechen.

Wie die Interceptorenkette funktioniert

In OkHttp bilden Interceptoren eine Kette. Jeder Interceptor erhält ein Chain-Objekt mit der ursprünglichen Anfrage und ruft chain.proceed(request) auf, um die Kontrolle an den nächsten Interceptor zu übergeben. Nach Erhalt der Antwort kann der Interceptor die Response analysieren, modifizieren, die Anfrage bei Fehler wiederholen oder eine benutzerdefinierte Antwort für die Zwischenspeicherung zurückgeben. Die Reihenfolge des Hinzufügens von Interceptoren zum OkHttpClient.Builder bestimmt ihre Ausführungsreihenfolge: der zuerst hinzugefügte wird beim Senden zuerst und beim Empfangen zuletzt ausgeführt.

Interceptor in OkHttp: Application und Network

OkHttp unterteilt Interceptoren in zwei Typen. Application Interceptor (addInterceptor) wird zwischen dem Anwendungscode und OkHttp ausgeführt: ein chain.proceed()-Aufruf — eine Anfrage an den Server, unabhängig von Weiterleitungen. Network Interceptor (addNetworkInterceptor) wird innerhalb von OkHttp nach der Header-Bildung und Verbindung ausgeführt — er wird bei jeder Weiterleitung, Wiederholung oder Authentifizierungsversuch ausgelöst. Diese Unterscheidung ist entscheidend für die Wahl des richtigen Interceptor-Typs für eine bestimmte Aufgabe.

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 — ein Application Interceptor, der Methode, URL, Antwortcode und Ausführungszeit protokolliert. Das Hinzufügen über addInterceptor() garantiert ein Protokoll pro Benutzeranfrage ohne Duplizierung bei Weiterleitungen. CacheInterceptor wird als Network Interceptor hinzugefügt, um Cache-Control-Header des Servers zu berücksichtigen, die nur innerhalb von OkHttp nach der Bildung der HTTP-Anfrage sichtbar sind.

Unterschied zwischen den Typen in der Praxis

Wenn die Anwendung eine Anfrage stellt, kann der Server mit einer 302- oder 301-Weiterleitung antworten. Application Interceptor sieht nur die endgültige Antwort nach allen Weiterleitungen — er weiß nicht, wie viele zwischengeschaltete Anfragen gestellt wurden. Network Interceptor sieht jede Anfrage und Antwort, einschließlich der zwischengeschalteten. Laut Square (2026) sieht Network Interceptor auch auf Verbindungsebene komprimierte Daten (gzip), während Application Interceptor die bereits dekomprimierte Antwort erhält. Um die tatsächliche Anzahl der Netzwerkaufrufe zu zählen, verwenden Sie Network Interceptor.

Alamofire RequestInterceptor

Alamofire stellt das RequestInterceptor-Protokoll bereit, das zwei Protokolle kombiniert: RequestAdapter zum Modifizieren der Anfrage vor dem Senden und RequestRetrier für Wiederholungsversuche bei Fehlern. Diese Trennung ermöglicht die flexible Kombination von Anpassung (Hinzufügen von Headern, Token) mit Wiederholungsrichtlinie (exponentieller Backoff, Versuchslimit, Fehlertypüberprüfung). RequestInterceptor wird durch eine einzige Struktur oder Klasse implementiert, die beide Protokolle erfüllt.

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 fügt in Swift über adapt ein Bearer-Token hinzu und wiederholt die Anfrage bei URLError (Netzwerkverlust, Zeitüberschreitung) automatisch über retry mit einer Verzögerung von 1 Sekunde. Die Trennung von Anpassung und Wiederholungen ermöglicht unabhängiges Testen — Sie können einen Unit-Test für die Anpassung schreiben, ohne die Wiederholungslogik zu beeinträchtigen. Laut Alamofire (2026) ist RequestInterceptor der Standardweg zur Zentralisierung der Authentifizierungsverwaltung in iOS-Projekten.

Anwendungsfälle für Interceptoren

Protokollierung — der häufigste Anwendungsfall. Der Interceptor zeichnet URL, Methode, Header, Anfrage- und Antwortkörper sowie Ausführungszeit auf. In Debug-Builds ersetzt dies Charles Proxy und Wireshark; in Release-Builds hilft es Absturzberichten mit Anforderungskontext. OkHttp verwendet HttpLoggingInterceptor aus der Bibliothek logging-interceptor mit den Stufen NONE, BASIC, HEADERS und BODY. Die Stufe BODY protokolliert vollständige Anfrage- und Antwortkörper — nur im Debug-Modus verwenden.

Authentifizierung und Token-Aktualisierung

Wenn das Zugriffstoken abläuft, fängt der Interceptor die 401-Antwort ab, ruft die Token-Aktualisierungs-API auf und wiederholt die ursprüngliche Anfrage mit dem neuen Token. In OkHttp wird dies über Authenticator oder einen benutzerdefinierten Interceptor mit response.code-Überprüfung implementiert. Der Authenticator hat nur Zugriff auf Antwort-Header, während der Interceptor Zugriff auf den vollständigen Körper hat. In Alamofire — über RequestRetrier, der nach Token-Aktualisierung .retry zurückgibt. Laut OWASP (2026) reduziert die automatische Token-Aktualisierung über Interceptor das Risiko von Anmeldedatenlecks.

Allgemeine Header hinzufügen

Content-Type, Accept-Language, User-Agent, Device-ID — Header, die in jeder Anfrage erforderlich sind. Der Interceptor fügt sie zentral hinzu, ohne Duplizierung in jeder API-Methode. User-Agent wird einmal beim App-Start gebildet: „AppName/1.0 (Android 14; Pixel 8”. Accept-Language wird aus der Systemsprache des Geräts übernommen. Laut Alamofire (2026) reduziert die zentrale Header-Verwaltung über Interceptor fehlerhafte Header-Fehler um 30%.

Bewährte Verfahren und Kettenreihenfolge

Die Reihenfolge des Hinzufügens von Interceptors in OkHttp bestimmt das Verhalten der gesamten Kette. Der zuerst hinzugefügte Interceptor wird beim Senden der Anfrage zuerst und beim Empfangen der Antwort zuletzt ausgeführt. Für die Protokollierung fügen Sie den Interceptor zuerst hinzu — er sieht die endgültige Anfrage mit allen Änderungen anderer Interceptoren. Für die Komprimierung fügen Sie ihn zuletzt hinzu, damit die Komprimierung auf die endgültigen Daten angewendet wird. Für die Authentifizierung fügen Sie ihn vor der Wiederholung hinzu, damit das Token vor dem nächsten Versuch aktualisiert wird.

Empfehlungen für Produktions-Builds

Deaktivieren Sie in Release-Builds die Protokollierung über BuildConfig.DEBUG oder Dependency Injection. Verwenden Sie addNetworkInterceptor für das Caching — Network Interceptor sieht die Cache-Control-Header des Servers und interpretiert die Caching-Richtlinie korrekt. Für die Authentifizierung verwenden Sie addInterceptor (Application) — dies verhindert ein erneutes Abfangen bei Weiterleitungen an Drittanbieter-Domains, an die Autorisierungs-Header nicht gesendet werden sollten. Testen Sie jeden Interceptor isoliert mit MockWebServer aus okhttp-testing-support — er fängt Anfragen ab und gibt vorbereitete Antworten zurück, sodass Sie die Interceptor-Logik ohne einen echten Server überprüfen können.

Interceptor-Leistung

Jeder Interceptor fügt der Anfragezeit eine kleine Verzögerung hinzu. In einer typischen Kette von 3-4 Interceptoren (Protokollierung, Authentifizierung, Komprimierung, Caching) beträgt der Overhead weniger als 5 Millisekunden pro Anfrage. Probleme treten auf, wenn ein Interceptor blockierende Operationen ausführt: synchroner Aufruf der Token-Aktualisierungs-API, Schreiben großer Protokolle in eine Datei oder Verschlüsseln des Anforderungskörpers. Alle diese Operationen sollten asynchron oder in einem Hintergrund-Thread ausgeführt werden. Laut Square (2026) führt OkHttp Interceptors im Dispatcher-Thread-Pool aus — das Blockieren eines Interceptors verzögert die gesamte Kette.

• Reihenfolge ist wichtig — Protokollierung zuerst, Authentifizierung vor Wiederholung, Komprimierung zuletzt
• Debug vs. Release — HttpLoggingInterceptor nur in Debug-Builds
• Isolation — jeder Interceptor erledigt eine Aufgabe (Einzelverantwortung)
• Asynchronität — Interceptor wird im OkHttp-Hintergrund-Thread ausgeführt, ohne die UI zu blockieren