Interceptor — vad det är, typer av interceptor i OkHttp och Alamofire

Vad är Interceptor?

Interceptor — en programvarukomponent som injiceras i HTTP-klienten för att fånga upp och ändra förfrågningar innan de skickas till servern och svar innan de överförs till appen. Inom mobilutveckling löser interceptor tvärgående uppgifter: automatisk tillägg av autentiseringstokens, trafikloggning med tidsmätning, återförsök vid tillfälliga nätverksfel, komprimering och dekryptering av data i farten. Interceptor-arkitekturen är baserad på Chain of Responsibility-mönstret — varje interceptor kan ändra begäran, utföra den eller avbryta kedjan genom att returnera ett anpassat svar.

Hur interceptor-kedjan fungerar

I OkHttp bildar interceptor en kedja (chain). Varje Interceptor får ett Chain-objekt med den ursprungliga begäran och anropar chain.proceed(request) för att överföra kontrollen till nästa interceptor. Efter att ha mottagit svaret kan interceptor analysera Response, ändra det, upprepa begäran vid fel eller returnera ett anpassat svar för cachning. Ordningen för att lägga till interceptor i OkHttpClient.Builder bestämmer deras körordning: den först tillagda körs först vid sändning och sist vid mottagning.

Interceptor i OkHttp: Application och Network

OkHttp delar in interceptor i två typer. Application Interceptor (addInterceptor) körs mellan applikationskoden och OkHttp: ett anrop av chain.proceed() — en begäran till servern, oavsett omdirigeringar. Network Interceptor (addNetworkInterceptor) körs inom OkHttp efter att rubriker och anslutning har skapats — utlöses vid varje omdirigering, återförsök eller autentisering. Denna skillnad är avgörande för att välja rätt interceptor-typ för en specifik uppgift.

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

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

LoggingInterceptor — en Application Interceptor som loggar metoden, URL:en, svarskoden och exekveringstiden. Tillägg via addInterceptor() garanterar en logg per användarbegäran utan dubbelarbete vid omdirigeringar. CacheInterceptor lades till som Network Interceptor för att ta hänsyn till serverns Cache-Control-rubriker, som endast är synliga inom OkHttp efter att HTTP-begäran har skapats.

Skillnad mellan typer i praktiken

När appen skickar en begäran kan servern svara med en 302- eller 301-omdirigering. Application Interceptor ser endast det slutgiltiga svaret efter alla omdirigeringar — det vet inte hur många mellanliggande begäranden som gjordes. Network Interceptor ser varje begäran och svar, inklusive mellanliggande. Enligt Square (2026) ser Network Interceptor även data som komprimerats på anslutningsnivå (gzip), medan Application Interceptor får ett redan dekomprimerat svar. För att räkna det faktiska antalet nätverksanrop, använd Network Interceptor.

Alamofire RequestInterceptor

Alamofire tillhandahåller protokollet RequestInterceptor, som kombinerar två protokoll: RequestAdapter för att ändra begäran före sändning och RequestRetrier för återförsök vid fel. Denna separation möjliggör flexibel kombination av anpassning (tillägg av rubriker, tokens) med återförsökspolicy (exponentiell fördröjning, begränsning av försök, kontroll av felttyp). RequestInterceptor implementeras av en enda struktur eller klass som implementerar båda protokollen.

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 i Swift lägger till Bearer-token via adapt och upprepar automatiskt begäran vid URLError (nätverksförlust, timeout) via retry med en fördröjning på 1 sekund. Separationen av anpassning och återförsök möjliggör oberoende testning — man kan skriva ett enhetstest för anpassning utan att påverka retry-logiken. Enligt Alamofire (2026) är RequestInterceptor standardsättet för centraliserad autentiseringshantering i iOS-projekt.

Användningsscenario för interceptor

Loggning — det vanligaste scenariot. Interceptor registrerar URL, metod, rubriker, begäran- och svarskropp, exekveringstid. I debug-byggen ersätter detta Charles Proxy och Wireshark, i release — hjälper felrapporter med begärankontext. För OkHttp används HttpLoggingInterceptor från biblioteket logging-interceptor med nivåerna NONE, BASIC, HEADERS och BODY. BODY-nivån loggar fullständiga begäran- och svarskroppar — använd endast i debug.

Autentisering och Refresh Token

När åtkomsttoken löper ut fångar Interceptor upp 401-svaret, anropar refresh token API och upprepar den ursprungliga begäran med den nya token. I OkHttp implementeras detta via Authenticator eller en anpassad Interceptor med response.code-kontroll. Authenticator har endast tillgång till svarsrubriker, Interceptor — till hela kroppen. I Alamofire — via RequestRetrier, som returnerar .retry efter token-uppdatering. Enligt OWASP (2026) minskar automatisk token-uppdatering via Interceptor risken för läckage av inloggningsuppgifter.

Tillägg av gemensamma rubriker

Content-Type, Accept-Language, User-Agent, Device-ID — rubriker som krävs i varje begäran. Interceptor lägger till dem centraliserat, utan dubbelarbete i varje API-metod. User-Agent skapas en gång vid appstart: ”AppName/1.0 (Android 14; Pixel 8)”. Accept-Language hämtas från enhetens systemspråk. Enligt Alamofire (2026) minskar centraliserad rubrikhantering via Interceptor antalet fel med felaktiga rubriker med 30%.

Bästa praxis och kedjeordning

Ordningen för att lägga till Interceptor i OkHttp bestämmer hela kedjans beteende. Den först tillagda interceptorn körs först vid sändning av begäran och sist vid mottagning av svar. För loggning lägg till Interceptor först — den kommer att se den slutgiltiga begäran med alla ändringar från andra interceptor. För komprimering — sist, så att komprimering tillämpas på slutgiltig data. För autentisering — före återförsök, så att token uppdateras före återförsök.

Rekommendationer för produktionsbyggen

I release-byggen, inaktivera loggning via BuildConfig.DEBUG eller beroendeinjektion. Använd addNetworkInterceptor för cachning — Network Interceptor ser serverns Cache-Control-rubriker och tolkar cachningspolicyn korrekt. För autentisering, använd addInterceptor (Application) — detta förhindrar återfångning vid omdirigeringar till externa domäner där auktoriseringsrubriker inte bör skickas. Testa varje Interceptor isolerat med MockWebServer från okhttp-testing-support — den fångar upp begäranden och returnerar förberedda svar, vilket möjliggör kontroll av interceptor-logik utan verklig server.

Interceptor-prestanda

Varje Interceptor lägger till en liten fördröjning till begäran-tiden. I en typisk kedja med 3–4 interceptor (loggning, autentisering, komprimering, cachning) är överheaden mindre än 5 millisekunder per begäran. Problem uppstår när Interceptor utför blockerande operationer: synkront anrop av refresh token API, skrivning av stora loggar till fil eller kryptering av begärankroppen. Alla dessa operationer bör vara asynkrona eller köras på en bakgrundstråd. Enligt Square (2026) kör OkHttp Interceptor i Dispatcher-trådpoolen — blockering av en interceptor fördröjer hela kedjan.

• Ordningen har betydelse — loggning först, autentisering före återförsök, komprimering sist
• Debug vs Release — HttpLoggingInterceptor endast i debug-byggen
• Isolering — varje Interceptor löser en uppgift (Single Responsibility)
• Asynkronitet — Interceptor körs på OkHttps bakgrundstråd, utan att blockera UI