Interceptor — mi ez, az OkHttp és Alamofire elfogótípusai

Mi az Interceptor?

Interceptor — szoftverkomponens, amelyet a HTTP-kliensbe injektálnak a kérések szerverre küldés előtti és a válaszok alkalmazásba továbbítás előtti elfogására és módosítására. Mobilfejlesztésben az elfogók keresztirányú feladatokat oldanak meg: hitelesítési tokenek automatikus hozzáadása, forgalom naplózása időméréssel, újrapróbálkozások ideiglenes hálózati hibáknál, adatok tömörítése és visszafejtése menet közben. Az Interceptor architektúrája a Chain of Responsibility mintán alapul — minden elfogó módosíthatja a kérést, végrehajthatja vagy megszakíthatja a láncot egy egyéni válasz visszaadásával.

Hogyan működik az elfogók lánca

Az OkHttp-ban az elfogók láncot (chain) alkotnak. Minden Interceptor egy Chain objektumot kap az eredeti kéréssel, és meghívja a chain.proceed(request) metódust a vezérlés következő elfogónak történő átadásához. A válasz kézhezvétele után az elfogó elemezheti a Response-t, módosíthatja, megismételheti a kérést hiba esetén, vagy egyéni választ adhat vissza gyorsítótárazáshoz. Az elfogók OkHttpClient.Builder-hez való hozzáadásának sorrendje határozza meg végrehajtásuk sorrendjét: az elsőként hozzáadott hajtódik végre elsőként küldéskor és utolsóként fogadáskor.

Interceptor OkHttp-ban: Application és Network

OkHttp két típusra osztja az elfogókat. Application Interceptor (addInterceptor) az alkalmazáskód és OkHttp között hajtódik végre: egy chain.proceed() hívás — egy kérés a szerverre, átirányításoktól függetlenül. Network Interceptor (addNetworkInterceptor) az OkHttp-n belül hajtódik végre a fejlécek és kapcsolat létrehozása után — minden átirányításnál, újrapróbálkozásnál vagy hitelesítésnél aktiválódik. Ez a különbség kritikus fontosságú a megfelelő elfogótípus kiválasztásához egy adott feladathoz.

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

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

LoggingInterceptor — Application Interceptor, amely naplózza a metódust, URL-t, válaszkódot és végrehajtási időt. Az addInterceptor()-en keresztüli hozzáadás garantálja a felhasználói kérésenként egy naplót az átirányításoknál történő duplikáció nélkül. CacheInterceptor Network Interceptorként lett hozzáadva, hogy figyelembe vegye a szerver Cache-Control fejléceit, amelyek csak az OkHttp-n belül láthatók a HTTP-kérés létrehozása után.

Különbség a típusok között a gyakorlatban

Amikor az alkalmazás kérést küld, a szerver 302-es vagy 301-es átirányítással válaszolhat. Application Interceptor csak a végső választ látja az összes átirányítás után — nem tudja, hány közbenső kérés történt. Network Interceptor minden kérést és választ lát, beleértve a közbensőket is. A Square (2026) adatai szerint a Network Interceptor a kapcsolat szintjén tömörített (gzip) adatokat is látja, míg az Application Interceptor már kicsomagolt választ kap. A tényleges hálózati hívások számának számlálásához használja a Network Interceptort.

Alamofire RequestInterceptor

Alamofire a RequestInterceptor protokollt kínálja, amely két protokollt egyesít: RequestAdapter a kérés küldés előtti módosításához és RequestRetrier az újrapróbálkozásokhoz hibák esetén. Ez a szétválasztás lehetővé teszi az adaptáció (fejlécek, tokenek hozzáadása) rugalmas kombinálását az újrapróbálkozási politikával (exponenciális késleltetés, próbálkozások korlátja, hibatípus ellenőrzése). A RequestInterceptor-t egyetlen struktúra vagy osztály valósítja meg, amely mindkét protokollt implementálja.

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 Swift-ben Bearer tokent ad hozzá az adapt-en keresztül, és automatikusan megismétli a kérést URLError (hálózatvesztés, timeout) esetén a retry-n keresztül 1 másodperces késleltetéssel. Az adaptáció és az újrapróbálkozások szétválasztása lehetővé teszi független tesztelésüket — egységteszt írható az adaptációhoz anélkül, hogy befolyásolná a retry logikát. A Alamofire (2026) adatai szerint a RequestInterceptor a szabványos módja a központosított hitelesítéskezelésnek iOS-projektekben.

Az elfogók használati forgatókönyvei

Naplózás — a leggyakoribb forgatókönyv. Az Interceptor rögzíti az URL-t, metódust, fejléceket, a kérés és válasz törzsét, a végrehajtási időt. Debug-összeállításokban ez helyettesíti a Charles Proxy-t és Wireshark-ot, release-ben — segíti a hibajelentéseket a kérés kontextusával. OkHttp-hoz a HttpLoggingInterceptor használatos a logging-interceptor könyvtárból NONE, BASIC, HEADERS és BODY szintekkel. A BODY szint naplózza a kérések és válaszok teljes törzsét — csak debug-ban használja.

Hitelesítés és Refresh Token

Amikor az access token lejár, az Interceptor elfogja a 401-es választ, meghívja a refresh token API-t és megismétli az eredeti kérést az új tokennal. OkHttp-ban ez Authenticator-on vagy egyéni Interceptor-on keresztül valósul meg response.code ellenőrzéssel. Az Authenticator csak a válasz fejléceihez fér hozzá, az Interceptor — a teljes törzshöz. Alamofire-ban — a RequestRetrier-en keresztül, amely .retry-t ad vissza a token frissítése után. A OWASP (2026) adatai szerint a tokenek automatikus frissítése Interceptor-on keresztül csökkenti a hitelesítő adatok kiszivárgásának kockázatát.

Közös fejlécek hozzáadása

Content-Type, Accept-Language, User-Agent, Device-ID — minden kérésben szükséges fejlécek. Az Interceptor központilag adja hozzá őket, minden API-metódusban történő duplikáció nélkül. A User-Agent egyszer jön létre az alkalmazás indításakor: „AppName/1.0 (Android 14; Pixel 8)". Az Accept-Language az eszköz rendszernyelvéből származik. Az Alamofire (2026) adatai szerint a fejlécek Interceptor-on keresztüli központosított kezelése 30%-kal csökkenti a hibás fejlécek számát.

Legjobb gyakorlatok és a lánc sorrendje

Az Interceptor OkHttp-hoz való hozzáadásának sorrendje meghatározza a teljes lánc viselkedését. Az elsőként hozzáadott elfogó hajtódik végre elsőként a kérés küldésekor és utolsóként a válasz fogadásakor. Naplózáshoz adja hozzá az Interceptort elsőként — látni fogja a végső kérést az összes többi elfogó módosításával. Tömörítéshez — utolsóként, hogy a tömörítés a végső adatokra kerüljön alkalmazásra. Hitelesítéshez — az újrapróbálkozás előtt, hogy a token frissüljön az újrapróbálkozás előtt.

Javaslatok production-összeállításokhoz

Release-összeállításokban kapcsolja ki a naplózást BuildConfig.DEBUG vagy függőséginjektálás segítségével. Gyorsítótárazáshoz használja az addNetworkInterceptor-t — a Network Interceptor látja a szerver Cache-Control fejléceit és helyesen értelmezi a gyorsítótárazási politikát. Hitelesítéshez alkalmazza az addInterceptor-t (Application) — ez megakadályozza az újbóli elfogást a külső tartományokra történő átirányításoknál, ahol az engedélyezési fejléceket nem szabad elküldeni. Teszteljen minden Interceptort elkülönítve a MockWebServer segítségével az okhttp-testing-support-ból — ez elfogja a kéréseket és előre elkészített válaszokat ad vissza, lehetővé téve az elfogó logikájának ellenőrzését valódi szerver nélkül.

Interceptor teljesítménye

Minden Interceptor kis késleltetést ad a kérés idejéhez. Egy tipikus 3–4 elfogóból álló láncban (naplózás, hitelesítés, tömörítés, gyorsítótárazás) a többletterhelés kevesebb, mint 5 ezredmásodperc kérésenként. A problémák akkor kezdődnek, amikor az Interceptor blokkoló műveleteket hajt végre: szinkron refresh token API hívás, nagy naplók fájlba írása vagy a kérés törzsének titkosítása. Mindezeknek a műveleteknek aszinkronnak kell lenniük vagy háttérszálon kell végrehajtódniuk. A Square (2026) adatai szerint az OkHttp az Interceptort a Dispatcher szálkészletben hajtja végre — egy elfogó blokkolása az egész láncot késlelteti.

• A sorrend számít — naplózás először, hitelesítés az újrapróbálkozás előtt, tömörítés utoljára
• Debug vs Release — HttpLoggingInterceptor csak debug-összeállításokban
• Elkülönítés — minden Interceptor egy feladatot old meg (Single Responsibility)
• Aszinkronság — az Interceptor az OkHttp háttérszálán hajtódik végre, nem blokkolja a UI-t