Interceptor — шта је то, врсте пресретача OkHttp и Alamofire

Шта је Interceptor?

Interceptor — програмска компонента уграђена у HTTP клијент за пресретање и измену захтева пре слања на сервер и одговора пре прослеђивања апликацији. У мобилном програмирању, пресретачи решавају попречне задатке: аутоматско додавање токена за аутентификацију, логирање саобраћаја са мерењем времена, поновни покушаји при привременим мрежним грешкама, компресија и дешифровање података у лету. Архитектура Interceptor-а се заснива на шаблону Chain of Responsibility — сваки пресретач може да измени захтев, изврши га или прекине ланац враћањем прилагођеног одговора.

Како ради ланац пресретача

У OkHttp пресретачи формирају ланац (chain). Сваки Interceptor добија објекат Chain са оригиналним захтевом и позива chain.proceed(request) за пренос контроле следећем пресретачу. Након пријема одговора, пресретач може да анализира Response, измени га, понови захтев при грешци или врати прилагођени одговор за кеширање. Редослед додавања пресретача у OkHttpClient.Builder одређује редослед њиховог извршавања: први додати се извршава први при слању и последњи при пријему.

Interceptor у OkHttp: Application и Network

OkHttp дели пресретаче на два типа. Application Interceptor (addInterceptor) се извршава између кода апликације и OkHttp: један позив chain.proceed() — један захтев на сервер, без обзира на преусмеравања. Network Interceptor (addNetworkInterceptor) се извршава унутар OkHttp након формирања заглавља и конекције — активира се на свако преусмеравање, поновни покушај или аутентификацију. Ова разлика је критична за правилан избор типа пресретача за одређени задатак.

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")
        return response
    }
}

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

LoggingInterceptor — Application Interceptor који логира метод, URL, код одговора и време извршавања. Додавање кроз addInterceptor() гарантује један лог по корисничком захтеву без дуплирања на преусмеравањима. CacheInterceptor је додат као Network Interceptor да би узео у обзир Cache-Control заглавља сервера, која су видљива само унутар OkHttp након формирања HTTP захтева.

Разлика између типова у пракси

Када апликација пошаље захтев, сервер може да одговори преусмеравањем 302 или 301. Application Interceptor ће видети само коначни одговор након свих преусмеравања — не зна колико је посредних захтева направљено. Network Interceptor ће видети сваки захтев и одговор, укључујући посредне. Према подацима Square (2026), Network Interceptor такође види податке компримоване на нивоу конекције (gzip), док Application Interceptor прима већ декомпримовани одговор. За бројање стварног броја мрежних позива користите Network Interceptor.

Alamofire RequestInterceptor

Alamofire пружа протокол RequestInterceptor, који обједињује два протокола: RequestAdapter за измену захтева пре слања и RequestRetrier за поновне покушаје при грешкама. Ово раздвајање омогућава флексибилно комбиновање адаптације (додавање заглавља, токена) са политиком поновних покушаја (експоненцијално кашњење, ограничење покушаја, провера типа грешке). RequestInterceptor се имплементира једном структуром или класом која имплементира оба протокола.

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-у додаје Bearer токен кроз adapt и аутоматски понавља захтев при URLError (губитак мреже, timeout) кроз retry са кашњењем од 1 секунде. Раздвајање адаптације и поновних покушаја омогућава њихово независно тестирање — може се написати јединични тест за адаптацију без утицаја на retry логику. Према подацима Alamofire (2026), RequestInterceptor је стандардни начин централизованог управљања аутентификацијом у iOS пројектима.

Сценарији коришћења пресретача

Логирање — најчешћи сценарио. Interceptor бележи URL, метод, заглавља, тело захтева и одговора, време извршавања. У debug верзијама ово замењује Charles Proxy и Wireshark, у release — помаже извештајима о грешкама са контекстом захтева. За OkHttp се користи HttpLoggingInterceptor из библиотеке logging-interceptor са нивоима NONE, BASIC, HEADERS и BODY. BODY ниво логира пуна тела захтева и одговора — користите само у debug.

Аутентификација и Refresh Token

Када access token истекне, Interceptor пресреће одговор 401, позива refresh token API и понавља оригинални захтев са новим токеном. У OkHttp се ово имплементира кроз Authenticator или прилагођени Interceptor са провером response.code. Authenticator има приступ само заглављима одговора, Interceptor — целом телу. У Alamofire — кроз RequestRetrier, који враћа .retry након освежавања токена. Према подацима OWASP (2026), аутоматско освежавање токена кроз Interceptor смањује ризик од цурења акредитива.

Додавање заједничких заглавља

Content-Type, Accept-Language, User-Agent, Device-ID — заглавља потребна у сваком захтеву. Interceptor их додаје централизовано, без дуплирања у свакој API методи. User-Agent се формира једном при покретању апликације: „AppName/1.0 (Android 14; Pixel 8)". Accept-Language се преузима из системског језика уређаја. Према подацима Alamofire (2026), централизовано управљање заглављима кроз Interceptor смањује број грешака неисправних заглавља за 30%.

Најбоље праксе и редослед ланца

Редослед додавања Interceptor у OkHttp одређује понашање целог ланца. Први додати пресретач се извршава први при слању захтева и последњи при пријему одговора. За логирање додајте Interceptor први — видеће коначни захтев са свим изменама од других пресретача. За компресију — последњи, да се компресија примени на коначне податке. За аутентификацију — пре поновног покушаја, да се токен освежи пре поновног покушаја.

Препоруке за production верзије

У release верзијама искључите логирање кроз BuildConfig.DEBUG или ињекцију зависности. Користите addNetworkInterceptor за кеширање — Network Interceptor види Cache-Control заглавља сервера и исправно тумачи политику кеширања. За аутентификацију примените addInterceptor (Application) — ово спречава поновно пресретање при преусмеравањима на спољне домене, где заглавља ауторизације не треба слати. Тестирајте сваки Interceptor изоловано помоћу MockWebServer из okhttp-testing-support — он пресреће захтеве и враћа унапред припремљене одговоре, омогућавајући проверу логике пресретача без стварног сервера.

Перформансе Interceptor-а

Сваки Interceptor додаје мало кашњење времену захтева. У типичном ланцу од 3–4 пресретача (логирање, аутентификација, компресија, кеширање) додатни трошак је мањи од 5 милисекунди по захтеву. Проблеми почињу када Interceptor извршава блокирајуће операције: синхрони позив refresh token API, упис великих логова у датотеку или шифровање тела захтева. Све ове операције треба да буду асинхроне или да се извршавају у позадинској нити. Према подацима Square (2026), OkHttp извршава Interceptor у пулу нити Dispatcher — блокирање једног пресретача задржава цео ланац.

• Редослед је важан — логирање прво, аутентификација пре поновног покушаја, компресија последња
• Debug vs Release — HttpLoggingInterceptor само у debug верзијама
• Изолација — сваки Interceptor решава један задатак (Single Responsibility)
• Асинхроност — Interceptor се извршава на позадинској нити OkHttp, не блокирајући UI