90% аналитиков на собеседованиях уверенно рассуждают про REST API, но сыплются на базовых вещах: путают PUT и PATCH, возвращают 200 там, где нужен конфликт, и не думают о повторных запросах. Для русскоязычной IT-аудитории это не академический спор, а очень прикладной фильтр: такие ошибки потом превращаются в лишние ретраи, дубль-события и поддержку, которая внезапно живет в логах.
Об этом как пишет Habr / Карьера, рассказал Сергей Прощаев, Tech Lead в FinTech и преподаватель OTUS. Вместо очередной лекции про REST он предложил формат самопроверки: три кейса из практики FinTech и e-commerce, на которых быстро становится понятно, кто читал спецификации, а кто действительно проектировал API под боевой трафик и живых клиентов.
Первый кейс выглядит почти безобидно: в сервисе подписок нужно отключить автопродление. На уровне контроллера соблазн очевиден: сделать что-то вроде POST для действия с говорящим глаголом в URL и закрыть задачу. Так часто и делают, особенно когда команда мыслит не ресурсами, а операциями. Проблема начинается позже, когда к этому добавляются мобильные клиенты, автоматические повторы запросов и интеграции, которые трактуют успех по-своему. Один лишний повтор, и «простое действие» внезапно плодит лишние уведомления, повторные события и мусор в журналировании.
Прощаев разбирает несколько вариантов и подводит к выводу, который многим не нравится именно своей приземленностью: для частичного изменения поля у ресурса логичнее использовать PATCH. В примере с автопродлением запрос с установкой значения false сохраняет понятную семантику и при повторе не меняет итоговое состояние. Формально RFC не обещает идемпотентность для PATCH вообще, но конкретная операция может быть идемпотентной, если второй и третий вызов не меняют результат. Это и есть тот кусок инженерного мышления, на котором интервью часто превращается в стресс-тест: кандидат должен не назвать «правильный метод», а объяснить, что произойдет, если клиент отправит один и тот же запрос дважды.
Отдельно полезен и другой вывод из этого кейса: action-oriented API сам по себе не ересь. В индустрии полно зрелых систем, где POST с глаголом в URL живет годами. Но такой стиль быстро разъезжается по швам, если в платформе нет жестких правил про единообразие, статусы, ретраи и побочные эффекты. Иными словами, спор «REST против RPC» сам по себе мало что дает. Гораздо важнее, понимает ли команда цену удобного shortcut сегодня и то, сколько он будет стоить через полгода, когда в систему придут новые клиенты и автоматизация.
Второй кейс бьет в еще более болезненное место: коды ответа. Сценарий простой, как форма регистрации в любом SaaS: клиент отправляет email и пароль, а email должен быть уникальным. Вопрос, который в реальном проекте обсуждают до первой аварии, звучит так: что вернуть, если пользователь с таким адресом уже существует? Значительная часть команд по инерции отвечает 200 и прячет ошибку в теле ответа. Формально запрос дошел, бизнес-логика сработала, JSON вернулся. Практически это означает, что HTTP превращается в декоративный транспорт, а клиентская обработка ошибок уезжает в самописные договоренности.
Именно здесь автор проводит полезную границу между синтаксической ошибкой, ошибкой валидации и бизнес-конфликтом. Если поле email не соответствует схеме или пароль не проходит базовые ограничения, спорить особо не о чем: это класс ошибок уровня запроса. Но если структура корректна, а операция упирается в текущее состояние системы, логика меняется. Конфликт уникальности email, по сути, и есть конфликт с уже существующим состоянием ресурса. Поэтому 409 Conflict в таком сценарии выглядит не экзотикой для педантов, а нормальным языком общения между сервером и клиентом.
Отдельная тонкость в том, что автор не продает один код ответа как религию. Он признает, что 422 используется многими современными API и фреймворками, а индустрия не договорилась о железной границе между 400, 409 и 422. Для практиков это, пожалуй, самый трезвый фрагмент материала. В больших командах проблема обычно не в том, что выбрали «не тот» статус из учебника, а в том, что внутри одной платформы одинаковые ошибки оформляются по-разному. В одном сервисе конфликт, в другом валидация, в третьем вообще 200 с флажком success. После этого любой SDK, gateway или просто фронтенд-команда начинают жить в режиме дешифровки намерений бэкенда.
Для разработчиков и системных аналитиков смысл статьи не сводится к чек-листу «запомни PATCH и 409». Материал показывает более неприятную правду про проектирование REST API: слабые решения почти всегда выглядят разумно в моменте. POST кажется быстрее, 200 кажется удобнее, отдельный подресурс кажется аккуратнее, пока никто не спросил про повторную доставку, обратную совместимость и единые правила платформы. Поэтому на интервью и в живой работе выигрывает не тот, кто цитирует RFC, а тот, кто умеет связать HTTP-семантику с поведением реальной системы: ретраями, логированием, поддержкой, изменением контрактов и стоимостью сопровождения.
Есть и более широкий контекст. Рынок давно сдвинулся от монолитных внутренних API, где все можно объяснить голосом в чате, к платформам, на которых висят мобильные приложения, партнерские интеграции, личные кабинеты, CRM и очередной микросервис, написанный «на пару недель». В такой среде качество API-дизайна перестает быть эстетикой для архитекторов. Это уже часть операционной устойчивости продукта. Неудачная семантика метода, размытые статусы и отсутствие дисциплины в контрактах редко ломают систему в день релиза, зато отлично делают это потом, когда любое исправление становится дорогим и политически сложным.
Поэтому главный вопрос после таких кейсов не в том, кто именно победит в вечном споре про PATCH, PUT или 422. Важнее другое: сколько команд в 2026 году все еще проектируют REST API как набор «удобных ручек», а не как публичный контракт, который должен пережить рост продукта, новые клиенты и неизбежные человеческие ошибки. Судя по опыту автора, собеседования этот разрыв показывают очень быстро. Production обычно показывает еще быстрее.
The post REST API на собеседовании: почему PATCH и 409 валят аналитиков appeared first on iTech News.