Все ли запросы были через GET

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

Вопрос обычно идёт после рассказа о проекте: интервьюер хочет понять, работали ли вы с сетевым слоем всерьёз или только получали списки. Если все запросы были GET, следом спросят, как приложение создавало и меняло данные и почему нельзя было сделать это тем же GET.

Как отвечать

Опишите реальный сетевой слой своего приложения: обычно это Retrofit поверх OkHttp, методы помечены @GET, @POST, @PUT, @PATCH, @DELETE. Затем покажите, что понимаете смысл каждого метода:

• GET: только чтение, безопасный и идемпотентный. Параметры в пути и query, тела нет. Retrofit не даст повесить @Body на @GET, OkHttp тоже откажется;
• POST: создание и действия вроде логина или оплаты. Не идемпотентен: повтор создаст второй заказ;
• PUT и PATCH: полная замена ресурса и частичное обновление. PUT идемпотентен, PATCH в общем случае нет;
• DELETE: идемпотентен, повторное удаление не должно ломать состояние.

Хорошо добавить мобильную специфику. Сеть в метро рвётся, запросы повторяются, поэтому для неидемпотентных операций сервер принимает заголовок Idempotency-Key. HTTP-кэш OkHttp (Cache) сохраняет только ответы на GET. Токены и персональные данные не кладут в query: адрес с параметрами попадает в логи сервера и в HttpLoggingInterceptor, даже когда трафик идёт по HTTPS.

Если в проекте был GraphQL, честно скажите, что почти всё шло через POST на один эндпоинт, и объясните почему. Если приложение действительно только читало данные, так и скажите, но покажите, что знаете, как устроены остальные методы.

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

Отвечают «да, всё через GET», включая авторизацию и отправку форм. Для интервьюера это сигнал, что вы не понимаете семантику методов.

Утверждают, что POST безопаснее GET, потому что данные «не видны». Без HTTPS видно всё, с HTTPS шифруется и адрес, разница только в логах и истории.

Забывают про повторы. Кандидат не может объяснить, что будет, если ответ на POST потерялся, а приложение отправило запрос ещё раз.