OkHttp — шта је то, могућности и архитектура HTTP клијента

Шта је OkHttp?

OkHttp је ефикасни HTTP клијент за Java, Android и Kotlin, развијен од стране компаније Square. Библиотека пружа нискоризиско API за извршавање HTTP захтева са подршком за HTTP/2, SPDY, WebSocket и аутоматско обнављање конекција при мрежним отказима.

OkHttp се појавио 2013. године као одговор на потребу за поузданим HTTP клијентом који би решио проблеме HttpURLConnection — недостатак pool-а конекција, слабу подршку за HTTP/2 и непријатно API. До 2025. године OkHttp се користи на системском нивоу Android API: OkHttp је уграђен у имплементацију HttpURLConnection од Android 4.4 (API 19).

Према подацима Google I/O 2024, OkHttp обрађује преко 70% свих HTTP захтева у Android екосистему. То је могуће зато што је OkHttp транспортни слој за Retrofit, Apollo GraphQL, Firebase и многе друге библиотеке. Програмери аутоматски добијају функционалност OkHttp без експлицитног повезивања.

Како ради OkHttp

Архитектура OkHttp је изграђена на ланцу пресретача (Interceptor chain). Сваки захтев пролази кроз низ пресретача који могу модификовати Request, Response или прекинути извршавање. Ова архитектура подсећа на образац Chain of Responsibility и омогућава флексибилно проширење функционалности.

Када апликација пошаље захтев, OkHttp извршава следеће кораке: разрешава DNS, бира конекцију из pool-а (или ствара нову), отвара TLS руковање (ако је HTTPS), шаље HTTP захтев, прима одговор и враћа га апликацији. RealCall је унутрашња класа која управља комплетним животним циклусом захтева од креирања до завршетка.

OkHttp аутоматски обрађује преусмеравања (302, 301), понавља захтеве при мрежним отказима (retry), прати протокол keep-alive и подржава транспарентну gzip компресију. Програмер не мора да пише код за ове операције — OkHttp их ради аутоматски на основу заглавља сервера.

Подршка за HTTP/2 и мултиплексирање

HTTP/2 омогућава слање више захтева преко једне TCP конекције истовремено, без блокирања (head-of-line blocking, својственог HTTP/1.1). OkHttp аутоматски користи HTTP/2 ако сервер подржава овај протокол и транспарентно прелази на HTTP/1.1 када је потребно.

Мултиплексирање HTTP/2 је посебно важно за мобилне апликације, где кашњење успостављања конекције (TCP + TLS) може износити 100–300 ms. Уместо 10 узастопних конекција, OkHttp користи једну, смањујући укупно кашњење за 40–60% на типичним Android уређајима са нестабилном конекцијом.

Пресретачи OkHttp: Interceptor и NetworkInterceptor

Interceptor је интерфејс са једним методом intercept(Chain) који прима Request, извршава радње и враћа Response. Пресретачи су два типа: пресретачи апликације (додају се преко addInterceptor) и мрежни пресретачи (addNetworkInterceptor).

Пресретачи апликације се активирају пре формирања HTTP захтева — они виде оригинални Request и коначни Response након свих трансформација. Мрежни пресретачи се активирају на мрежном нивоу: они виде захтев након gzip компресије, додавања Content-Length заглавља, преусмеравања и поновних покушаја. Мрежни пресретачи се не позивају ако је одговор добијен из кеша.

Примена пресретача у пракси

У пракси пресретачи OkHttp решавају три главна задатка: ауторизацију (додавање Authorization заглавља), логирање (HttpLoggingInterceptor за отклањање грешака) и понављање (аутоматско понављање захтева при мрежним отказима). Комбиновањем више пресретача може се изградити комплетан pipeline обраде захтева без дуплирања кода у сваком HTTP позиву апликације.

Редослед додавања пресретача је битан: Interceptor додат први се извршава први на улазу и последњи на излазу. За NetworkInterceptor редослед одређује мрежни стек. Препоручени редослед: AuthInterceptor (додаје токен), LoggingInterceptor (логира захтев), RetryInterceptor (понавља при отказима).

Логирање преко HttpLoggingInterceptor

За отклањање грешака мрежних захтева користи се HttpLoggingInterceptor — готови пресретач од Square. Он логира метод, URL, заглавља и тело захтева и одговора. Нивои логирања: BASIC (метод + URL + код), HEADERS (са заглављима) и BODY (пун захтев и одговор). BODY је користан током развоја, али се на продукцији искључује из безбедносних и перформансних разлога.

Примери кода OkHttp у Kotlin

Размотримо основни GET захтев преко OkHttp. Прво се креира OkHttpClient — тешки објекат који се креира једном и поново користи. Затим се формира Request са URL-ом, и захтев се извршава синхроно преко execute или асинхроно преко enqueue.

val client = OkHttpClient.Builder()
    .connectTimeout(15, TimeUnit.SECONDS)
    .readTimeout(15, TimeUnit.SECONDS)
    .build()

val request = Request.Builder()
    .url("https://api.github.com/users/octocat")
    .header("Accept", "application/vnd.github.v3+json")
    .build()

val response = client.newCall(request).execute()
println(response.body()?.string())

За асинхроно извршавање користи се метод enqueue који прима Callback. OkHttp извршава захтев у позадинској нити и враћа резултат у callback-у на истој нити. За пребацивање на главну Android нит користите Handler или корутине.

client.newCall(request).enqueue(object : Callback {
    override fun onFailure(
        call: Call, e: IOException
    ) {
        println("Захтев није успео: ${e.message}")
    }

    override fun onResponse(
        call: Call, response: Response
    ) {
        println(response.body()?.string())
    }
})

Додавање пресретача за ауторизацију

Прилагођени Interceptor додаје Bearer токен сваком захтеву. Пресретач проверава присуство Authorization заглавља, и ако токен још није постављен, додаје га из складишта. При одговору 401, пресретач може ажурирати токен преко Authenticator-а.

class AuthInterceptor(
    private val tokenProvider: () -> String?
) : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val originalRequest = chain.request()
        val token = tokenProvider.invoke()
        val request = originalRequest.newBuilder()
            .header("Authorization", "Bearer $token")
            .build()
        return chain.proceed(request)
    }
}

Pool конекција и кеширање OkHttp

Pool конекција (ConnectionPool) — кључна оптимизација OkHttp која омогућава поновно коришћење TCP конекција за више захтева. Уместо стварања новог socket-а за сваки захтев, OkHttp чува до 5 неактивних конекција (подразумевано) током 5 минута, што смањује кашњење за 30–70% за поновљене захтеве ка истом host-у.

Кеширање одговора се имплементира преко класе Cache. За укључивање кеша довољно је навести директоријум и максималну величину у OkHttpClient.Builder. OkHttp аутоматски кешира GET одговоре према Cache-Control, Expires и ETag заглављима, враћајући кеширане податке без мрежног захтева ако нису застарели.

val cacheDir = File(context.cacheDir, "http-cache")
val cache = Cache(cacheDir, 10L * 1024 * 1024)

val client = OkHttpClient.Builder()
    .cache(cache)
    .connectionPool(ConnectionPool(5, 5, TimeUnit.MINUTES))
    .build()

Правилно подешавање pool-а и кеша је посебно важно за апликације са честим захтевима — вести, четови, ажурирања података. Без pool-а, свака TCP конекција захтева тросмерно руковање (SYN, SYN-ACK, ACK) и потенцијално TLS руковање (2–3 round-trip), што додаје 100–500 ms сваком захтеву.

OkHttp такође подржава WebSocket преко класе RealWebSocket. WebSocket конекција се успоставља преко HTTP руковања (101 Switching Protocols) и затим прелази на двосмерни протокол. OkHttp аутоматски шаље ping оквире за одржавање конекције живом и поново се повезује при прекиду. WebSocket од OkHttp је компатибилан са стандардним endpoint-има попут wss://echo.websocket.org.

Типичне грешке при раду са OkHttp

Креирање OkHttpClient за сваки захтев — најчешћа грешка. OkHttpClient садржи pool конекција, кеш и pool нити. Креирање нове инстанце за сваки захтев не само да троши меморију, већ и лишава предности поновног коришћења конекција. OkHttpClient треба да буде синглтон кроз DI контејнер.

Игнорисање затварања Response.body() доводи до цурења ресурса. ResponseBody садржи InputStream који се мора затворити након читања. Ако се користи body().string() или body().bytes(), OkHttp затвара ток аутоматски, али при читању body().byteStream() или body().charStream() потребно је експлицитно позвати close() у finally блоку.

Недостатак обраде Timeout-а — још један проблем. Подразумевано OkHttp нема timeout (connectTimeout = 10 секунди, readTimeout = 10 секунди, writeTimeout = 10 секунди). За мобилне апликације са нестабилном конекцијом препоручује се подешавање connectTimeout 15–30 секунди и readTimeout 15–30 секунди, иначе ће корисник превише дуго чекати при слабом сигналу.