Как выбрать код состояния HTTP в REST API для "Не готов еще, попробуйте снова позже"?

Я разрабатываю API RESTful, в котором http://server/thingyapi/thingyblob/1234 возвращает файл (aka "blob" ), связанный с thingy # 1234 для загрузки. Но может быть, запрос выполняется в тот момент, когда файл не существует на сервере, но наиболее определенно будет доступен позднее. Там есть пакетный процесс на сервере, который генерирует все капли для всех вещей. Thingy 1234 уже существует, и его данные, кроме blob, уже доступны. Сервер еще не получил генератор 1234 blob.

Я не хочу возвращать 404; что для вещей, которые не существуют. Это вещь, которая существует, но ее blob еще не создан. Kinda, как видео на YouTube, которое "обрабатывает". Я не думаю, что коды переадресации были бы правильными; нет "другого" URL-адреса, чтобы попробовать.

Какой правильный код состояния HTTP будет возвращен в таком случае?

Ответ 1

Я предлагаю 202 - Accepted. Из документации:

Запрос принят для обработки, но обработка еще не завершена. [...] Его цель - разрешить серверу принимать запрос на какой-либо другой процесс (возможно, пакетно-ориентированный процесс, который запускается только один раз в день).

Ответ 2

"Проблема", например, есть на стороне сервера: клиент сделал хорошо сформированный запрос, но сервер не может его удовлетворить. Поэтому я склонен к "Ошибка сервера", код состояния 5xx. Quoth стандарт:

Коды состояния ответа, начинающиеся с цифры "5", указывают случаи, когда сервер знает, что он ошибся или не способен выполнить запрос... сервер ДОЛЖЕН включать объект [указывающий], является ли он временным или постоянное состояние.

Примечание

  • "erred или не может выполнить запрос": несмотря на название "Ошибка сервера", они не только для ошибок сервера.
  • " временный или постоянный": эти коды подходят для временно недоступных ресурсов, таких как ваши.

Из доступных кодов, я бы сказал 503, "Service Unavailable" был наилучшим образом подходит:

В настоящее время сервер не может обработать запрос из-за временной перегрузки или обслуживания сервера. Подразумевается, что это временное условие, которое будет смягчено после некоторой задержки. Если известно, длина задержки МОЖЕТ указываться в заголовке Retry-After. Если Retry-After не задано, клиенту СЛЕДУЕТ обрабатывать ответ, как это было бы для ответа 500.

Примечание:

  • "временное условие, которое будет смягчено после некоторой задержки": true для вашего случая.
  • "временная перегрузка": не имеет отношения к вашему делу. Но, можно утверждать, был ли ваш сервер намного быстрее, пакетная обработка уже была бы выполнена, когда клиент сделал запрос, поэтому это своего рода "перегрузка": клиент запрашивает ресурсы быстрее, чем может сделать сервер они доступны.
  • "клиент ДОЛЖЕН обрабатывать ответ, как это было бы для ответа 500.": это "Внутренняя ошибка сервера", тип ответа, когда сервер терпит неудачу из-за ошибки. Стандарт, по-видимому, подразумевает, что в этом случае хороший человек не должен повторять попытку. Повторная попытка подходит для вашего обслуживания, поэтому ваш ответ должен включать значение Retry-After. Вы можете указать в качестве значения предполагаемое время завершения следующего выполнения пакетного процесса или интервал выполнения пакетного процесса.

Определение вашего собственного кода состояния 5xx (например, 591), хотя разрешено, будет иметь неправильную семантику:

Коды состояния HTTP являются расширяемыми... приложения ДОЛЖНЫ понимать класс любого кода состояния, как указано первой цифрой, и рассматривать любой непризнанный ответ как эквивалентный коду состояния x00 этого класса

Клиенты будут обрабатывать ваш собственный код состояния как 500, "Внутренняя ошибка сервера", которая (как я уже говорила выше) была бы неправильной.

Ответ 3

Другая опция: 503 - Service Unavailable.

Ответ 4

Поскольку ваш ресурс не готов, вы, вероятно, знаете, когда (примерно) он будет доступен, и когда клиент может повторить свой запрос. Это означает, что вы можете использовать заголовок Retry-After. Этот заголовок действителен с 503 (Service Unavailable), что означает, что весь сайт не работает для обслуживания, и ответы 3xx (перенаправление).

На мой взгляд, лучшим вариантом будет 302 (Найдено) с заголовком Retry-After, но я не уверен, что поле Location заголовка ответа может быть равно запросу url. Во всяком случае, это круговое перенаправление.

Ответ 5

Я не хочу возвращать 404; что для вещей, которые не существуют.

URL-адрес не соответствует запросу на предмет.

http://server/thingyapi/thingyblob/1234

Клиент запрашивает thingyblob, которого не существует. Если бы он существовал, вы бы дали им их.

404.

Ответ 6

Я думаю, что 423 - Locked можно использовать для этой цели:

Код статуса 423 (заблокированный) означает, что исходный или целевой ресурс метода заблокирован. Этот ответ ДОЛЖЕН содержать подходящее предварительное условие или код условия, например, "блокировка-токен-отправленный" или "неконфликтный блокировка".

Ответ 7

501 - Не реализовано

Точно так же, как это звучит. Функция, которая еще не реализована, но подразумевает будущую доступность.

Вот ссылка на сводку ошибок 5xx.

Ответ 8

409 Конфликт

Указывает, что запрос не может быть обработан из-за конфликта в запросе, такого как конфликт изменений в случае нескольких обновлений. [Источник Wikipedia.]

Это может быть уместно.

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

Я думаю, что у вас есть конфликт.. вы хотите данные.. но его редактирование/обновление. Это также будет иметь место, если Thingy1234 уже существовал и был успешно загружен ранее, но теперь он был в процессе редактирования, был недоступен, пока редактирование происходило.