Когда в системе есть заявка, платёж или обращение, очень легко начать проектирование с эндпоинтов: POST /create GET /status POST /cancel Но проблема часто не в API, а в том, что никто нормально не договорился, какие состояния вообще существуют и как объект между ними переходит. Например, для платежа недостаточно двух статусов: SUCCESS и ERROR. Могут понадобиться: CREATED → PROCESSING → SUCCESS а ещё: DECLINED, UNKNOWN, CANCELLED, MANUAL_REVIEW. И дальше начинаются правильные вопросы: — из какого статуса можно сделать повторную попытку; — можно ли отменить уже исполняемую операцию; — что делать после timeout; — какой статус считается финальным; — кто может вручную изменить состояние; — какие переходы вообще запрещены. Если этого не определить заранее, каждый сервис начинает трактовать статусы по-своему. В итоге API формально работает, а бизнес-процесс — нет. Поэтому в интеграционных задачах я люблю сначала собрать status/state model, а уже потом проектировать методы API и обработку ошибок. Это простой шаг, который сильно уменьшает количество спорных сценариев на разработке и тестировании.