Как реализован механизм общения по REST

Что проверяют

Понимаете ли вы, что REST это архитектурный стиль, а не библиотека, и как запрос проходит от кнопки до сервера в вашем приложении. Следом обычно просят рассказать, как обрабатываются ошибки и что происходит с запросом при повороте экрана.

Как отвечать

Коротко про сам стиль: ресурсы адресуются URL, операции выражаются методами HTTP, сервер не хранит состояние клиента между запросами. GET безопасный и идемпотентный, PUT и DELETE идемпотентные, POST нет, PATCH нужен для частичного обновления. Итог передаётся кодом ответа: 2xx успех, 4xx ошибка клиента, 5xx ошибка сервера.

Дальше опишите стек слоями:

• OkHttp: транспорт. Пул соединений, HTTP/2, кэш по Cache-Control, интерсепторы для токена и логирования, Authenticator для обновления токена по 401;
• Retrofit: поверх OkHttp. Интерфейс с аннотациями @GET, @POST, @Path, @Query, @Body, методы suspend, разбор JSON через конвертер (kotlinx.serialization, Moshi или Gson);
• репозиторий: оборачивает вызовы, превращает исключения и коды в доменный результат, решает, отдать ли данные из Room;
• ViewModel: запускает запрос в viewModelScope, поэтому поворот экрана его не обрывает, а уход с экрана отменяет;
• DI: Retrofit и OkHttpClient создаются один раз через Hilt или Koin. Каждый лишний клиент заводит свой пул соединений и кэш.

В Kotlin Multiplatform вместо Retrofit обычно берут Ktor Client.

Полезно знать деталь: suspend-метод, который возвращает тело, бросает HttpException на коде вне 2xx, а метод с типом Response<T> отдаёт код вам.

Где спотыкаются

Пишут catch (e: Exception) вокруг suspend-вызова. Так глотается и CancellationException, и корутина, которую уже отменили, продолжает работать.

Делают запрос прямо из Activity или Fragment. После поворота он повторяется или результат приходит в уничтоженный экран.

Путают REST с «JSON по HTTP» и не могут объяснить, чем PUT отличается от POST и почему повтор POST после таймаута может создать дубль.