REST API ломается не на «теории ресурсов», а на мелочах: статусы, идемпотентность, частичные обновления, конфл

REST API ломается не на «теории ресурсов», а на мелочах: статусы, идемпотентность, частичные обновления, конфликты версий. В реальных проектах именно тут чаще всего и всплывают баги.

Разбор из практики:
- **GET/POST/PUT/PATCH** — не «на вкус команды», а про семантику.
`PUT` должен быть идемпотентным: 10 одинаковых запросов → один и тот же результат.
- **409 Conflict** — не просто «ошибка», а сигнал о столкновении состояний: версия сущности устарела, дубль уже существует, optimistic locking сработал.
- **PATCH** — хорош для частичных изменений, но только если вы четко описали формат патча и правила валидации.

На собесе хороший тест: спросить, как API поведет себя при повторной отправке запроса после таймаута. Если ответ про retriable operations, idempotency keys и корректные коды ответов — человек проектировал API, а не заучивал REST по шпаргалке ⚙️

Мини-чеклист:
1. Для каждого метода прописать семантику и идемпотентность.
2. Для конфликтов завести отдельные коды, не лепить везде 400.
3. Для PATCH заранее описать схему изменений и ограничения.

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