Настройка Retrofit для сетевых запросов в Android-приложении

Разработка сетевого слоя на Retrofit часто натыкается на подводные камни: неожиданный 401, ошибки парсинга, утечка токенов. Один из наших проектов — приложение для банковского сервиса — требовал надёжной авторизации с обновлением токена. Без настройки Authenticator OkHttp каждый запрос к защищённому ресурсу возвращал ошибку. Нам пришлось переписать логику, чтобы избежать ручной обработки в каждом UseCase. За 5 лет работы над 20+ проектами мы выработали типовую конфигурацию, которая сокращает время разработки сетевого слоя на 30–50%. Рассмотрим best practices настройки сетевого слоя на Retrofit.

Как настроить авторизацию в Retrofit?

Авторизация строится на двух компонентах: Interceptor для добавления заголовка и Authenticator для обновления токена. Interceptor читает токен из защищённого хранилища (EncryptedSharedPreferences) и подставляет его в каждый запрос. Если сервер возвращает 401, Authenticator пытается обновить токен через refresh-эндпоинт и повторяет запрос. Это избавляет от копирования логики авторизации по всему проекту и работает с любыми OAuth2-провайдерами.

class AuthInterceptor(private val tokenProvider: TokenProvider) : Interceptor { override fun intercept(chain: Interceptor.Chain): Response { val request = chain.request().newBuilder() .addHeader("Authorization", "Bearer ${tokenProvider.getToken()}") .build() return chain.proceed(request) } } class TokenAuthenticator( private val tokenProvider: TokenProvider, private val refreshApi: RefreshApi ) : Authenticator { override fun authenticate(route: Route?, response: Response): Request? { synchronized(this) { val newToken = tokenProvider.getToken() ?: return null if (response.request.header("Authorization") == "Bearer $newToken") { val refreshed = refreshApi.refresh(newToken) if (refreshed.isSuccessful) { tokenProvider.saveToken(refreshed.body()!!.accessToken) return response.request.newBuilder() .header("Authorization", "Bearer ${refreshed.body()!!.accessToken}") .build() } } } return null } } 

Почему KotlinX Serialization предпочтительнее Gson?

В Kotlin-проектах kotlinx.serialization даёт преимущества: null-safety на уровне парсинга, поддержка sealed классов и работа без рефлексии. Это особенно важно при обфускации через R8, так как рефлексивные вызовы Gson могут сломаться. По нашим замерам, KotlinX обрабатывает JSON в 2–3 раза быстрее Gson на объёмах от 100 КБ. Кроме того, размер APK увеличивается всего на ~50 КБ против ~200 КБ у Gson.

Интерсепторы OkHttp

Здесь концентрируется большая часть логики сетевого слоя. Помимо авторизации, типовые интерсепторы:

• Логирование: HttpLoggingInterceptor с уровнем BODY только для debug-сборки. В production — NONE, чтобы не логировать чувствительные данные.
• Retry: кастомный интерсептор с экспоненциальной задержкой для IOException. Коды 4xx и 5xx не повторяем — только сетевые сбои.
• Timeout: connectTimeout(30, TimeUnit.SECONDS), readTimeout(30, TimeUnit.SECONDS), writeTimeout(30, TimeUnit.SECONDS). Для загрузки файлов используем отдельный клиент с увеличенным writeTimeout.

Типичные ошибки при настройке:

• Неверный baseUrl: обязательно завершающий слеш /.
• Отсутствие INTERNET-пермишена в манифесте.
• Хранение токена в SharedPreferences без шифрования — используйте EncryptedSharedPreferences.
• Забыли добавить логгер в debug-сборке — отладка займёт часы.

Обработка ошибок

Suspend-функции Retrofit выбрасывают HttpException при статусах не 2xx и IOException при сетевых проблемах. Оборачиваем в sealed class:

sealed class ApiResult<out T> { data class Success<T>(val data: T) : ApiResult<T>() data class Error(val code: Int, val message: String) : ApiResult<Nothing>() data object NetworkError : ApiResult<Nothing>() } 

Это позволяет ViewModel обрабатывать ошибки типизированно без try/catch на каждом вызове. Логика обёртки вынесена в NetworkDataSource. Для unit-тестов используем MockWebServer — симулируем ответы и проверяем корректность парсинга. Такой подход сокращает время на отладку интеграции на 20–30%.

Как мы работаем над сетевым слоем

Наш процесс включает этапы:

1. Аналитика — определяем эндпоинты, форматы запросов/ответов, фиксируем требования к безопасности.
2. Проектирование — выбираем стек (Retrofit + OkHttp + сериализатор), проектируем интерфейсы и модели данных.
3. Реализация — пишем код сетевого слоя, настраиваем интерсепторы, обработку ошибок, unit-тесты.
4. Тестирование — интеграционные тесты с MockWebServer, проверка сценариев авторизации, retry, timeout.
5. Деплой — интеграция в CI/CD, настройка productFlavors для разных окружений.

Что входит в работу по настройке сетевого слоя

• Документация API (формат, эндпоинты, примеры запросов/ответов)
• Полный код сетевого слоя (интерфейсы, интерсепторы, модели)
• Unit-тесты и интеграционные тесты (покрытие не менее 80%)
• Конфигурация CI/CD для сборки разных окружений
• Code review и рекомендации по дальнейшему расширению
• Поддержка в течение 2 недель после сдачи

Стоимость настройки сетевого слоя варьируется от 30 000 до 70 000 руб. в зависимости от сложности интеграции. Сроки: от 1 до 3 дней.

Как настроить Retrofit за 5 шагов

1. Подключите зависимости в build.gradle.kts:

   implementation("com.squareup.retrofit2:retrofit:2.9.0") implementation("com.squareup.okhttp3:okhttp:4.12.0") implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.6.0") 

   Получите консультацию по настройке сетевого слоя для вашего Android-приложения. Свяжитесь с нами, чтобы обсудить ваш проект.

   Дополнительные материалы: Retrofit и OkHttp — официальные источники по этим библиотекам.