REST API — это тот самый участок, где у команды внезапно выясняется, кто проектировал систему, а кто просто чи

REST API — это тот самый участок, где у команды внезапно выясняется, кто проектировал систему, а кто просто читал про неё в метро.

Есть классический фейл: на собеседовании кандидат бодро рассказывает про GET/POST/PATCH, а потом в живом кейсе из FinTech или e-commerce у него API начинает жить своей жизнью. Где-то метод обновления меняет только половину сущности, где-то 409 конфликт “ну как-нибудь переживём”, а где-то вообще нет понятной логики ошибок. И дальше начинается любимый цирк: фронт винит бэк, бэк винит бизнес, бизнес винит “неплохую документацию” 😏

Самое интересное — даже опытные инженеры спорят о базовых вещах: когда нужен PATCH, а когда безопаснее PUT, как правильно отдавать ошибки и где проводить границу между “можно повторить запрос” и “не трогайте, всё сломается”.

Умение проектировать API — это не про знание терминов. Это про то, как система переживает реальные нагрузки, дубль-запросы, конфликт данных и человеческую логику, которой иногда нет.

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