Кратко

  • 202 Accepted означает, что запрос принят в обработку, но сама обработка ещё не завершена.
  • Операция всё ещё может быть отклонена, отменена, просрочена, лишиться полномочий или завершиться без ожидаемого эффекта.
  • Решение, зависящее от завершения, требует подтверждения асинхронной операции, связывающего исходный запрос с официальным монитором состояния и конечным результатом.

Представим контроллер изменений, который запрашивает ротацию политики доступа. Сервис отвечает 202 Accepted и даёт ссылку на операцию. Контроллер отмечает изменение выполненным, отзывает старые учётные данные и удаляет входные материалы. Через несколько минут операция доходит до исполнителя, который повторно проверяет политику и отклоняет её. Запрос был принят. Изменение так и не было выполнено.

Ошибка не в коде состояния. Ошибка — в превращении одного этапа распределённой операции в доказательство всех последующих этапов.

RFC 9110 задаёт узкое значение 202 Accepted. Сервер принял запрос для обработки, однако обработка не завершена. В дальнейшем запрос может быть выполнен, а может быть признан недопустимым в момент фактической обработки. Ответ намеренно не содержит обязательства относительно исхода.

Эта граница важна, поскольку HTTP-обмен уже завершён. RFC 9110 отмечает, что HTTP не предоставляет способа позднее повторно передать код состояния асинхронной операции в рамках законченного обмена. Клиент, считающий первый 202 окончательным успехом, выдумывает продолжение, которого протокол не доставлял.

Представление ответа должно описывать текущее состояние и указывать на монитор состояния либо включать его. Это полезная рекомендация, но одна URL-ссылка ещё не подтверждает завершение. Монитор должен служить официальным источником состояния той же операции, быть доступным в предполагаемом контексте безопасности, сохраняться достаточно долго для принятия решения и явно различать конечные состояния. Общая страница очереди, изменяемая точка «последняя задача» или ссылка, которая позже отвечает 404, не могут обосновать необратимое решение.

RFC 7240 добавляет связанный, но отдельный сигнал. Клиент может отправить Prefer: respond-async, выражая предпочтение асинхронной обработки, а сервер — учесть его ответом 202. Предпочтение выбирает форму взаимодействия, но не доказывает выполнение отложенной работы. Способ узнать итоговый результат спецификация оставляет реализации.

Область действия Preference-Applied столь же узка. Согласно RFC 7240, это поле показывает, какие предпочтения запроса сервер применил. Оно может подтвердить выбор асинхронного режима, но не запуск исполнителя, запись, уведомление, развёртывание или иной последующий эффект.

Операционный журнал должен сохранять как минимум три разных факта. Первый — принятие: какие байты запроса, запрашивающая сторона, цель, ключ идемпотентности и ответ наблюдались и в какой точке. Второй — выполнение: какой идентификатор попал в какую очередь, какой исполнитель его забрал, какие проверки полномочий и зависимостей были актуальны и вмешались ли отмена или истечение срока. Третий — результат: какие эффекты зафиксированы, какое конечное состояние возвращено и остаётся ли оно официальным источником данных.

Эти связи легко теряются. Шлюз может выдать 202, тогда как очередью владеет другой сервис. URL операции может обозначать задачу относительно арендатора и менять смысл при других учётных данных. Повтор может найти ту же задачу либо создать вторую, если идемпотентность отсутствует. Исполнитель может начать работу уже после утраты полномочий субъектом запроса. Статус «успех» может появиться до того, как нижестоящий эффект станет наблюдаемым.

Ни одна из этих возможностей не делает 202 ошибочным. Асинхронное принятие ценно именно тем, что соединение не нужно держать открытым на протяжении долгой операции. Дисциплина состоит в сохранении ответа как свидетельства принятия и получении последующих доказательств для последующих утверждений.

Полезный объект доказательства — подтверждение асинхронной операции. Оно связывает метод, цель и дайджест тела запроса с аутентифицированной запрашивающей стороной, состоянием её полномочий в соответствующий момент, ключом идемпотентности, точкой наблюдения, ответом 202, идентификатором операции и URI официального монитора состояния. Затем оно фиксирует поступление в очередь, получение исполнителем, свежие проверки полномочий и зависимостей, состояние отмены, идентификаторы эффектов, конечный результат, время наблюдения и решение, использовавшее этот результат.

Источники

RFC 9110 — HTTP Semantics, 202 Accepted; RFC 7240 — Prefer Header for HTTP.