Один вопрос про REST API, который отсеивает джунов за 30 секунд

"Чем отличается PUT от PATCH?" Ты слышишь этот вопрос, и внутренне расслабляешься — лёгкий же. Но именно на нём интервьюер за 30 секунд понимает, стоит ли разговаривать дальше.

Не потому что вопрос сложный. А потому что глубина ответа мгновенно выдаёт уровень.

Вопрос

"Чем отличается PUT от PATCH в REST API?"

Его задают на собесах для бэкенд-разработчиков, фулстеков, системных аналитиков. По данным статей на Хабре, REST API — одна из тем, которую спрашивают практически на каждом техническом интервью, независимо от стека.

Почему его задают

Не чтобы проверить, читал ли ты документацию. Интервьюер хочет понять:

• Ты проектировал API или только дёргал чужие эндпоинты?
• Ты думаешь о побочных эффектах или пишешь код "лишь бы работало"?
• Ты понимаешь, что происходит, когда сеть теряет пакеты и клиент повторяет запрос?

Один вопрос — три уровня проверки.

Плохой ответ

"PUT заменяет ресурс целиком, PATCH обновляет частично."

Технически верно. Но это определение из первого абзаца любой статьи про REST. Интервьюер кивнёт и задаст follow-up: "А когда что использовать? А что с идемпотентностью?" И вот тут джун ломается.

Ещё хуже — ответ через пример без понимания:

"PUT — это как обновить весь объект пользователя, а PATCH — только email."

Это описание, а не понимание. Интервьюер ищет инженера, который думает о последствиях, а не пересказывает туториал.

Хороший ответ

"PUT — идемпотентная замена ресурса целиком. Отправляешь полное представление объекта — сервер заменяет то, что есть, на то, что пришло. Если отправить тот же PUT дважды — результат не изменится.

PATCH — частичное обновление. Отправляешь только те поля, которые нужно изменить. Но PATCH не гарантирует идемпотентность. Если PATCH устанавливает значение — он идемпотентен. Если инкрементирует счётчик — нет. Повторный запрос изменит результат.

На практике это важно для retry-логики. Если клиент не получил ответ и повторяет запрос — PUT безопасно повторить, а с PATCH нужно думать: не задвоится ли операция?"

Этот ответ показывает три вещи: ты знаешь определение, понимаешь идемпотентность на уровне реальных сценариев, и думаешь о том, что происходит, когда что-то идёт не так. Именно это отличает мидла от джуна.

Что на самом деле проверяют

Уровень 1 — Определение. PUT заменяет, PATCH обновляет частично. Это джуниорский уровень. Если кандидат остановился здесь — он на уровне "читал документацию".

Уровень 2 — Идемпотентность. PUT идемпотентен, PATCH — не всегда. Кандидат понимает, почему это важно: retry, сетевые сбои, дублирование операций. Это уровень мидла, который работал с реальными API в продакшене.

Уровень 3 — Дизайн-решения. Когда выбрать PUT, когда PATCH, и что делать, если нужен идемпотентный PATCH. Например:

// Неидемпотентный PATCH — опасно повторять
PATCH /accounts/123
{ "balance_change": +500 }

// Идемпотентный PATCH — безопасно повторять
PATCH /accounts/123
{ "balance": 1500 }

Кандидат, который объясняет разницу между этими двумя подходами и когда использовать какой — это сеньор-уровень мышления. Он не просто знает API — он проектирует его.

Бонус-уровень — Связь с реальной архитектурой. Как идемпотентность связана с очередями сообщений, exactly-once delivery, и почему некоторые платёжные API требуют idempotency key в заголовке. Если кандидат вышел на этот уровень — собес фактически пройден.

Как подготовиться к таким вопросам

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

Для каждого HTTP-метода спроси себя: "Что произойдёт, если этот запрос выполнится дважды?" GET — ничего, данные те же. POST — создаст дубликат. PUT — перезапишет тем же. DELETE — второй раз вернёт 404. PATCH — зависит от реализации. Если ты можешь объяснить каждый случай — ты готов.

Проектируй, а не запоминай. Возьми любой API, с которым работаешь, и задай вопрос: "Почему здесь PUT, а не PATCH? Что будет при retry?" Если работаешь с SQL, подумай, как операции с базой связаны с идемпотентностью API — INSERT vs UPDATE vs UPSERT.

Практикуй ответы вслух. Интервьюер оценивает не только знания, но и как ты их излагаешь. Рассуждение вслух от определения через идемпотентность к дизайн-решениям — это ровно то, что хотят услышать.

Хочешь потренировать ответы на вопросы про REST API и другие бэкенд-темы в режиме реального собеса? Sobes AI задаёт вопросы, оценивает глубину ответа и подсказывает, где ты остановился раньше, чем нужно.