Код статуса HTTP 200 против 202

Question

У меня есть Python + requests сценарий.

Шаги, которые скрипт должен выполнить:

• отправить файл в БД;
• одобрить этот файл (изменить состояние файла в БД);
• скачать файл.

Ограничение:

только одобренные файл может быть загружен

Мой код:

requests.post(url_to_create, files={"file": open(path_to_file)}) 
requests.post(url_to_approve, data={'id': file_id}) 
requests.get(url_to_download, data={'id': file_id}) 

Проблема:

Этот код работает почти идеально, но иногда я не получаю никакого файла. Я обнаружил, что первый и третий запросы возвращают код состояния 200, а второй возвращает 202. Как я понимаю (скажите мне, если я ошибаюсь) статус 202: Accepted означает, что сервер принимает запрос и возвращает код состояния без фактического завершения запроса

Вопрос:

Означает ли это, что запрос на загрузку можно отправить даже если запрос на одобрение еще не завершен, и, если это так, как я могу дождаться, пока запрос утверждения не будет завершен до отправки запроса на загрузку?

Answer 1

Это зависит от реализации вашего сервера, и ваш сервер решает, как будет обрабатываться 202.

202 Принято

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

Ответ 202 намеренно не регулируется. Его цель - , позволяющая серверу принимать запрос на какой-либо другой процесс (возможно, пакетный процесс , который выполняется только один раз в день) без , требуя, чтобы соединение пользователя с сервером сохранялось до , процесс завершен , Объект, возвращенный с этим ответом СЛЕДУЕТ включать указание текущего состояния запроса и либо указатель на монитор состояния, либо оценку того, когда пользователь может ожидать, что запрос будет выполнен.

Если тело ответа пуста, имеет смысл проверить заголовки ответов, которые должны содержать дополнительную информацию.

Reference - https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html