Interceptor — co to je, typy zachycovačů OkHttp a Alamofire

Co je Interceptor?

Interceptor — softwarová komponenta vložená do HTTP klienta pro zachycení a úpravu požadavků před odesláním na server a odpovědí před předáním aplikaci. V mobilním vývoji řeší zachycovače průřezové úkoly: automatické přidávání autentizačních tokenů, protokolování provozu s měřením času, opakování při dočasných síťových chybách, kompresi a dešifrování dat za běhu. Architektura Interceptoru je založena na vzoru Chain of Responsibility — každý zachycovač může upravit požadavek, provést jej nebo přerušit řetězec vrácením vlastní odpovědi.

Jak funguje řetězec zachycovačů

V OkHttp tvoří zachycovače řetězec (chain). Každý Interceptor obdrží objekt Chain s původním požadavkem a volá chain.proceed(request) pro předání řízení dalšímu zachycovači. Po obdržení odpovědi může zachycovač analyzovat Response, upravit jej, opakovat požadavek při chybě nebo vrátit vlastní odpověď pro ukládání do mezipaměti. Pořadí přidávání zachycovačů v OkHttpClient.Builder určuje pořadí jejich provádění: první přidaný se provádí první při odesílání a poslední při přijímání.

Interceptor v OkHttp: Application a Network

OkHttp rozděluje zachycovače na dva typy. Application Interceptor (addInterceptor) se provádí mezi kódem aplikace a OkHttp: jedno volání chain.proceed() — jeden požadavek na server, bez ohledu na přesměrování. Network Interceptor (addNetworkInterceptor) se provádí uvnitř OkHttp po vytvoření hlaviček a připojení — spouští se při každém přesměrování, opakování nebo autentizaci. Tento rozdíl je kritický pro správný výběr typu zachycovače pro konkrétní úkol.

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

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

LoggingInterceptor — Application Interceptor, který protokoluje metodu, URL, kód odpovědi a čas provedení. Přidání přes addInterceptor() zaručuje jeden záznam na uživatelský požadavek bez duplikace při přesměrováních. CacheInterceptor byl přidán jako Network Interceptor, aby zohlednil hlavičky Cache-Control serveru, které jsou viditelné pouze uvnitř OkHttp po vytvoření HTTP požadavku.

Rozdíl mezi typy v praxi

Když aplikace odešle požadavek, server může odpovědět přesměrováním 302 nebo 301. Application Interceptor uvidí pouze konečnou odpověď po všech přesměrováních — neví, kolik mezilehlých požadavků bylo provedeno. Network Interceptor uvidí každý požadavek a odpověď, včetně těch mezilehlých. Podle údajů Square (2026), Network Interceptor také vidí data komprimovaná na úrovni připojení (gzip), zatímco Application Interceptor obdrží již dekomprimovanou odpověď. Pro počítání skutečného počtu síťových volání použijte Network Interceptor.

Alamofire RequestInterceptor

Alamofire poskytuje protokol RequestInterceptor, který kombinuje dva protokoly: RequestAdapter pro úpravu požadavku před odesláním a RequestRetrier pro opakování při chybách. Toto oddělení umožňuje flexibilní kombinaci adaptace (přidávání hlaviček, tokenů) s politikou opakování (exponenciální zpoždění, limit pokusů, kontrola typu chyby). RequestInterceptor je implementován jednou strukturou nebo třídou implementující oba protokoly.

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 ve Swift přidává Bearer token přes adapt a automaticky opakuje požadavek při URLError (ztráta sítě, timeout) přes retry se zpožděním 1 sekunda. Oddělení adaptace a opakování umožňuje jejich nezávislé testování — lze napsat unit test pro adaptaci bez ovlivnění logiky retry. Podle údajů Alamofire (2026), RequestInterceptor je standardní způsob centralizované správy autentizace v iOS projektech.

Scénáře použití zachycovačů

Protokolování — nejčastější scénář. Interceptor zaznamenává URL, metodu, hlavičky, tělo požadavku a odpovědi, čas provedení. V debug sestaveních to nahrazuje Charles Proxy a Wireshark, v release — pomáhá hlášením chyb s kontextem požadavku. Pro OkHttp se používá HttpLoggingInterceptor z knihovny logging-interceptor s úrovněmi NONE, BASIC, HEADERS a BODY. Úroveň BODY protokoluje kompletní těla požadavků a odpovědí — používejte pouze v debug.

Autentizace a Refresh Token

Když access token vyprší, Interceptor zachytí odpověď 401, zavolá refresh token API a zopakuje původní požadavek s novým tokenem. V OkHttp se to implementuje přes Authenticator nebo vlastní Interceptor s kontrolou response.code. Authenticator má přístup pouze k hlavičkám odpovědi, Interceptor — k celému tělu. V Alamofire — přes RequestRetrier, který vrací .retry po obnovení tokenu. Podle údajů OWASP (2026), automatické obnovování tokenů přes Interceptor snižuje riziko úniku přihlašovacích údajů.

Přidávání společných hlaviček

Content-Type, Accept-Language, User-Agent, Device-ID — hlavičky vyžadované v každém požadavku. Interceptor je přidává centralizovaně, bez duplikace v každé API metodě. User-Agent se vytváří jednou při spuštění aplikace: „AppName/1.0 (Android 14; Pixel 8)". Accept-Language se přebírá ze systémového jazyka zařízení. Podle údajů Alamofire (2026), centralizovaná správa hlaviček přes Interceptor snižuje počet chyb nesprávných hlaviček o 30%.

Nejlepší postupy a pořadí řetězce

Pořadí přidávání Interceptoru v OkHttp určuje chování celého řetězce. První přidaný zachycovač se provádí první při odesílání požadavku a poslední při přijímání odpovědi. Pro protokolování přidejte Interceptor jako první — uvidí konečný požadavek se všemi úpravami od ostatních zachycovačů. Pro kompresi — jako poslední, aby se komprese aplikovala na konečná data. Pro autentizaci — před opakováním, aby se token obnovil před opakováním.

Doporučení pro produkční sestavení

V release sestaveních vypněte protokolování přes BuildConfig.DEBUG nebo injekci závislostí. Pro ukládání do mezipaměti použijte addNetworkInterceptor — Network Interceptor vidí hlavičky Cache-Control serveru a správně interpretuje politiku ukládání do mezipaměti. Pro autentizaci použijte addInterceptor (Application) — to zabraňuje opětovnému zachycení při přesměrováních na externí domény, kam by autorizační hlavičky neměly být odesílány. Testujte každý Interceptor izolovaně pomocí MockWebServer z okhttp-testing-support — zachycuje požadavky a vrací předem připravené odpovědi, což umožňuje kontrolu logiky zachycovače bez skutečného serveru.

Výkon Interceptoru

Každý Interceptor přidává malé zpoždění k času požadavku. V typickém řetězci 3–4 zachycovačů (protokolování, autentizace, komprese, mezipaměť) je režie menší než 5 milisekund na požadavek. Problémy začínají, když Interceptor provádí blokující operace: synchronní volání refresh token API, zápis velkých logů do souboru nebo šifrování těla požadavku. Všechny tyto operace by měly být asynchronní nebo prováděné na vlákně na pozadí. Podle údajů Square (2026), OkHttp provádí Interceptor v poolu vláken Dispatcher — zablokování jednoho zachycovače zpožďuje celý řetězec.

• Pořadí má význam — protokolování první, autentizace před opakováním, komprese poslední
• Debug vs Release — HttpLoggingInterceptor pouze v debug sestaveních
• Izolace — každý Interceptor řeší jeden úkol (Single Responsibility)
• Asynchronnost — Interceptor se provádí na vlákně na pozadí OkHttp, neblokuje UI