Правильный способ использования кода состояния 503 (Сервис недоступен)
У меня есть простая конечная точка API "api/machines/sum", которая интегрируется с другой службой API для обработки значения.
Иногда API, который я интегрирую, может быть отключен или недоступен. Итак, я пытался вернуть 503 - Служба недоступна для моего API, так как моя служба не может ничего обработать с зависимым API в автономном режиме.
Моя служба API работает нормально, но иждивенцы нет.
Семантически описание «служба недоступна» имеет для меня смысл. Это правильный способ использования кода состояния 503?
образец:
public async Task<IActionResult> Sum(string value)
{
try
{
ProcessValueFromAnotherAPI(id);
}
catch (AppIntegrationException)
{
return StatusCode(StatusCodes.Status503ServiceUnavailable, "custom message");
}
}
Ответы 2
Это интересный вопрос, потому что часто 503 относится к фактической службе, которую вы вызываете (в данном случае к вашему API). Я думаю, что более уместно вернуть нормальный ответ от вашего API, но, возможно, с объектом, определяющим статус:
{ "status" : "offline" }
Это сообщает вызывающей стороне, что ваш API исправен, и это не двусмысленно, если бы ваш API действительно возвращал 503.
Иногда API, который я интегрирую, может быть отключен или недоступен. Итак, я пытался вернуть 503 - Служба недоступна для моего API, так как моя служба не может ничего обработать с зависимым API в автономном режиме.
Звучит неплохо.
Тот факт, что ваш исходный сервер имеет внешние зависимости, является деталью реализации; и это не то, что мы обычно описываем в метаданных HTTP.
Вместо этого вы можете использовать 500 Internal Error . Основное отличие, которое делает 503 Service Unavailable интересным, заключается в том, что у нас есть доступная семантика Retry-After — мы можем стандартизированным образом сообщить клиенту нашу текущую оценку того, когда обслуживание будет восстановлено.
Другой возможностью было бы свернуть свой собственный код состояния.
599 BLAME SOMEONE ELSE
Компоненты общего назначения, которые не распознают код, будут рассматривать его как внутреннюю ошибку 500. Риск заключается в том, что более поздние усилия по стандартизации зарегистрируют ваш код, и тогда вам придется наводить порядок.
Если вы считаете, что у вас есть случай, когда эта семантика здесь общедоступна, то вы можете приступить к написанию спецификации и проработать процесс добавления вашего кода в реестр .
Все ошибки сервера ДОЛЖНЫ включать представление отправлять представление объяснения ошибки.
Таким образом, информация, представляющая интерес для сущности, сгенерировавшей запрос, но не обязательно представляющая интерес для компонентов общего назначения, должна присутствовать в теле сообщения HTTP-ответа.