На собеседованиях REST часто проверяют как теорию, а не как мышление. И это быстро видно: человек может перечи

На собеседованиях REST часто проверяют как теорию, а не как мышление. И это быстро видно: человек может перечислить методы, но спотыкается на границах ответственности, конфликте данных и сценариях, где «по учебнику» не работает.

В разборе три кейса из FinTech и e-commerce:
— где уместен PATCH, а где лучше не делать вид, что частичное обновление решает проблему;
— почему 409 — не «лишний код», а инструмент для честной обработки конфликтов;
— как проектировать API так, чтобы фронт, бэк и аналитика не спорили на каждом изменении.

Главный вывод простой: хороший REST — это не про красивый список эндпоинтов, а про предсказуемость системы и ответственность за решения.
Если на интервью человек уверенно объясняет, что произойдёт в спорных сценариях, — это уже не учебник, а рабочий опыт. 🔧