API проектируют не “по учебнику”, а по конфликтам.

API проектируют не “по учебнику”, а по конфликтам.

Если упростить тему до лобового теста, тут всего 3 проверки:
1) умеет ли человек отличать PUT от PATCH не по определению, а по риску для данных;
2) понимает ли, что 409 — это не “ошибка ради ошибки”, а защита от дубля и гонки;
3) может ли он собрать контракт так, чтобы бизнес-логика не расползлась по 15 ручкам.

Главная ошибка джунов и многих “опытных” — проектировать endpoint’ы как список хотелок, а не как систему ограничений. В итоге:
- статус-коды используются рандомно,
- частичное обновление ломает целостность,
- ретраи создают дубли,
- фронт и бэк начинают спорить не о API, а о том, кто виноват.

Нормальный API — это не красивый JSON. Это заранее зашитая защита от ошибок, дублей и ручного исправления данных 🔧

Если при разборе кейса человек не может объяснить, где будет конфликт, кто его ловит и почему, значит он API не проектировал — он его просто видел.