202 Accepted. В отчёте появилась зелёная отметка: операция завершена.Только доступы ещё не изменились.
В учебном сценарии перевода сотрудника между командами API отвечает
202, когда ставит запрос в очередь. Дальше операция может ждать исполнения, выполняться, завершиться успешно, упасть целиком или применить только часть изменений. Сам HTTP-ответ не говорит, какой из этих исходов произошёл.Здесь смешиваются два разных факта:
- технический факт: сервис принял запрос;
- бизнес-факт: у сотрудника действительно появился нужный доступ и исчез старый.
Первый можно подтвердить сразу. Для второго нужно продолжить наблюдение.
Проверка начинается с идентификатора операции. По нему система отслеживает состояние до терминального результата и сохраняет итог каждого шага. Если новая роль выдана, а старая не отозвана, это не «почти готово». Это отдельное состояние частичного успеха с задачей на восстановление.
После терминального статуса всё равно остаётся ещё одна проверка: запросить фактический набор ролей и сопоставить его с ожидаемым. Только так можно отличить запись «шаг выполнен» от реального результата для пользователя и процесса.
В постановке это меняет само определение завершённости. Нельзя писать: «операция успешна, если API вернул 202». Нужна цепочка:
1. запрос принят и получил идентификатор;
2. операция дошла до терминального состояния;
3. каждый обязательный шаг подтверждён;
4. фактическое состояние сверено с ожидаемым;
5. частичный результат не скрыт за общим зелёным статусом.
Та же ошибка встречается далеко за пределами управления доступом. Задача поставлена в очередь, файл обещан в JSON, письмо передано провайдеру, платёж принят в обработку. Во всех этих случаях ответ системы может означать «начали», хотя интерфейс уже показывает «готово».
Поэтому асинхронный контракт нужно читать как протокол наблюдения. Команда запускает работу. Статусы описывают её ход. Сверка подтверждает результат. Если остановиться на первом зелёном ответе, аналитик проверит транспорт и пропустит бизнес-исход.