REST API часто «ломают» не кодом, а плохой схемой контрактов. На собеседованиях это видно сразу: человек знает

REST API часто «ломают» не кодом, а плохой схемой контрактов. На собеседованиях это видно сразу: человек знает слова, но путается в статусах, идемпотентности и частичных обновлениях.

3 типовых провала из практики FinTech и e-commerce:

1) PATCH вместо PUT «на глаз»
Поле обновили частично, а клиент отправил весь объект. В итоге затираются данные, которые он даже не видел. Если ресурс редактируется целиком — нужен PUT с полной моделью. Если только часть — PATCH, но с жёстко описанным форматом.

2) 409 используют как универсальную ошибку
Конфликт — это не «что-то пошло не так». 409 нужен, когда запрос валидный, но состояние ресурса не позволяет его выполнить: дубль заказа, версия записи устарела, гонка при оплате. Для остального есть 400, 422, 500.

3) Нет явной стратегии версионирования
API меняют, клиенты — нет. Без версионирования ломается мобильное приложение, интеграция банка или CRM. Версия должна быть видна в контракте, а не спрятана в надежде, что «никто не заметит».

Чёрный вывод простой: если API не проверяют на конфликты, полные/частичные обновления и совместимость версий, инцидент — вопрос времени. 🔧