Как на собеседовании описать организацию сетевого слоя на URLSession без сторонних библиотек?

Как на собеседовании описать организацию сетевого слоя на URLSession без сторонних библиотек?

• сетевое взаимодействие в iOS с использованием URLSession
• проектирование абстракции для запросов разных типов: GET, POST и других
• создание Network Manager с отдельными методами для различных API-запросов
• настройка запроса через URLRequest: адрес, HTTP-метод, заголовки и тело
• обработка результата с помощью замыканий (completion handlers)
• преобразование полученных данных в модели посредством JSONDecoder
• обработка сетевых ошибок, HTTP-ответов и ошибок парсинга
• поддержка асинхронного выполнения через completion или async/await (iOS 15+)
• повторное использование кода, соблюдение принципа DRY, тестируемость и возможность расширения
• при необходимости — добавление кеширования, отмены запросов и настройки таймаутов
• практический пример: централизованный слой для REST API без обязательного подключения сторонних libs

Идея заключается в том, чтобы построить лёгкий, универсальный и расширяемый слой на базе URLSession для всех сетевых операций, предоставив удобный интерфейс и корректную обработку ошибок.

Подробный ответ

Основной ответ

Сетевой слой на URLSession без сторонних библиотек представляет собой чистый, расширяемый и удобный для тестирования компонент, который работает с сетевыми запросами средствами iOS. С самого начала стоит определить необходимые абстракции: это упростит смену реализаций и позволит единообразно обрабатывать разные виды запросов и ответов.

Ключевые моменты

• Модель запроса/ответа: Опишите запрос с помощью протоколов или структур, предусмотрев HTTP-метод, URL, параметры и заголовки. Для ответа определите механизм разбора, например декодирование JSON в Codable-модели. В частности, URLRequest можно последовательно собирать внутри фабрики.
• URLSession с конфигурацией: Настройте URLSession с собственной конфигурацией, задав, например, timeout и cachePolicy. Создание и отправку запроса следует скрыть внутри отдельного сетевого менеджера, который возвращает результат через коллбэк или Result, содержащий типизированные данные и ошибку.
• Обработка ошибок и статусов: Нужно проверять HTTP-коды, сетевые сбои и результат разбора ответа. Для разных ситуаций полезно определить собственные ошибки: отсутствие сети, таймаут или некорректный формат данных.
• Асинхронность: В современных проектах предпочтение обычно отдают async/await (начиная со Swift 5.5+), хотя замыкания также остаются допустимым вариантом. Такой код проще читать и удобнее тестировать.
• Тестируемость: Введите протокол, абстрагирующий сетевой слой, например NetworkClient или NetworkService. Благодаря этому в юнит-тестах настоящий сетевой вызов можно заменить моками.

Практический контекст

В реальных проектах я реализовывал такой слой на основе URLSessionDataTask, обёрнутого в сервис с методами func request<T:Decodable>(_ endpoint: Endpoint) async throws -> T. Это оставляет пространство для дальнейшего добавления кеширования, логирования, повторных попыток и фильтрации ошибок без библиотек вроде Alamofire.

Такой вариант является стандартным для продакшн-разработки под iOS, если важны минимальный вес решения и полный контроль. Он особенно удобен для команд, которым внутренние правила или бюджет не позволяют использовать сторонние библиотеки.