REST API БЕЗ ОШИБОК: ТРИ ГРАБЛИ, НА КОТОРЫЕ ВСТАЮТ ДАЖЕ СИНИОРЫ

REST API БЕЗ ОШИБОК: ТРИ ГРАБЛИ, НА КОТОРЫЕ ВСТАЮТ ДАЖЕ СИНИОРЫ

На собесе все любят рассказывать, как «проектировали API». А потом начинаются танцы: PUT или PATCH, когда возвращать 409, и почему у них в ответах внезапно живёт зоопарк из 200/201/204.

Разбор не про учебник. Про живые кейсы из FinTech и e-commerce, где API ломают не те, кто «не знает REST», а те, кто забыл базовую вещь: контракт важнее вкусовщины.

Что обычно валят:
— делают PATCH как «частичный PUT» и потом сами же не могут это поддерживать;
— лепят 200 на всё подряд, будто код статуса — декоративный элемент;
— игнорируют конфликт состояний, а потом ловят 409 уже в проде 🧨

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

Проверить себя полезно хотя бы затем, чтобы не выглядеть человеком, который «REST знает», но проектировал его только в теории.