REST API обычно ломается не на слове `GET`, а на деталях, которые на собесе выдают «читал, но не проектировал»

REST API обычно ломается не на слове `GET`, а на деталях, которые на собесе выдают «читал, но не проектировал».

3 задачи, где кандидаты чаще всего спотыкаются:

1) Выбор метода
`POST` или `PUT`, `PATCH` или `DELETE` — тут важен не учебник, а поведение системы. Если операция частично меняет ресурс, `PATCH` выглядит логично. Но как только появляется идемпотентность, начинаются споры.

2) Ошибки и коды ответа
`409 Conflict` — не для красоты. Он нужен, когда запрос валиден, но конфликтует с текущим состоянием. Это тот самый маркер: человек понимает логику домена или просто копирует таблицу HTTP-кодов.

3) Контракт и версия
Если API живёт в FinTech или e-commerce, «потом поправим» не работает. Поля, обязательность, обратная совместимость — это не бюрократия, а страховка от тихих падений 🛠

Быстрый чек-лист:
— есть ли у операции понятный ресурс
— совпадает ли метод с поведением
— описаны ли ошибки и конфликтные сценарии
— не сломает ли изменение старых клиентов

Хороший REST — это не про красивый Swagger. Это про то, как система ведёт себя под нагрузкой и в спорных кейсах.