Код состояния HTTP для "отсутствия данных" из внешнего источника данных

Сценарий:

Запрос

A POST отправляется для обработки заказа, который приведет к извлечению данных из внешнего источника данных.

Есть три возможных результата:

  • Источник данных возвратил данные для запроса
  • В запросе не было данных (это рассматривается как ошибка)
  • Не удалось получить доступ к источнику данных (может быть недоступен для обслуживания)

Очевидным ответом для 1 является 200: OK или 201: Created (сущность создается из этого запроса).

Какие коды статуса подходят для 2 и 3?

Коды состояния, которые я рассмотрел:

  • 503: Service Unavailable при отсутствии источника данных
  • 500: Internal Server Error при отсутствии источника данных
  • 502: Bad Gateway, когда "нет данных"
  • 404: Not Found, когда "нет данных"
  • 403: Forbidden, когда "нет данных"
  • 412: Precondition Failed, когда "нет данных"

ОТВЕТЫ

Ответ 1

2) Оглядываясь назад, я согласен, что это, вероятно, должно быть либо 204 No Content, либо, может быть, 200 с телом, указывающим отсутствие записей или ресурсов в зависимости от возвращаемой структуры. 404 обычно используются, когда URI ресурса не существует или ресурс в URI не найден в случае службы восстановления.

3) 503 Услуга недоступна

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

  Note: The existence of the 503 status code does not imply that a
  server must use it when becoming overloaded. Some servers may wish
  to simply refuse the connection.

Ответ 2

3) Я согласен с 503 для этого

2) Честно говоря, я думаю, что хороший аргумент может быть сделан для использования 204 в случае 2. Вы можете включить metainfo в заголовок, чтобы конкретно указать, что "пошло не так". Это действительно зависит от того, насколько вы считаете этот случай "ошибкой" на уровне API.

Если сам API функционирует так, как предполагалось, и запрос был действительной конечной точкой, авторизованным и авторизованным пользователем и не вызывал сбоя в работе сервера, то очень немногие из ошибок серии 400 или 500 действительно выглядели бы подать выражение.

например, 404 обычно означает, что URI, который вы вызывали, не существует, если он существует, то использование этого кода вводит в заблуждение, по крайней мере, IMHO

**10.2.5 204 No Content**

Сервер выполнил запрос, но ему не нужно возвращать сущность-тело и может захотеть вернуть обновленную метаинформацию. ответ МОЖЕТ включать новую или обновленную метаинформацию в форме сущности-заголовки, которые, если они ДОЛЖНЫ быть связаны с запрошенный вариант.

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

Ответ 204 НЕ ДОЛЖЕН включать тело сообщения и, следовательно, всегда завершается первой пустой строкой после полей заголовка.