На собеседованиях REST часто проверяют не по чеклисту, а по тому, как человек принимает решения в спорных мест

На собеседованиях REST часто проверяют не по чеклисту, а по тому, как человек принимает решения в спорных местах.

Я бы смотрел не на знание терминов, а на 3 вещи:
— как кандидат описывает ресурс и его границы;
— что делает, когда нужно обновить только часть объекта;
— как объясняет конфликт данных и почему тут появляется 409.

Именно на этих задачах видно, проектировал ли человек API руками или просто повторяет учебник.
В FinTech и e-commerce это особенно заметно: там один неверный статус или неудачный PATCH потом ломает интеграции, аналитику и поддержку.

Полезный формат для проверки себя — не «что такое REST», а разбор живых кейсов:
1. где PUT уместнее PATCH;
2. когда ошибка должна быть 400, а когда 409;
3. как не перегрузить ответ лишними полями.

Если нужно быстро отсеять слабых кандидатов или прокачать команду, такие задачи работают лучше любого теоретического теста 🔍