Наиболее подходящий код состояния HTTP для ответа «ухудшенный» статус от конечной точки работоспособности - это не что иное, как 200 OK.
Я говорю это потому, что не могу найти лучшего кода в официальном реестре кодов состояния Протокол передачи гипертекста (HTTP) , поддерживаемом IANA, на который указывает [RFC7231] HTTP/1.1: семантика и контент .Следует избегать неофициальных кодов, потому что они только усложняют понимание вашего API.
Вы должны разработать свои API так, чтобы они стали простыми в использовании.Имена ресурсов, HTTP-глаголы, коды состояния и т. Д. Должны быть более или менее понятны, чтобы люди, которые уже знают «язык REST», могли сразу понять, как использовать ваш API, без необходимости расшифровывать смутные имена или необычные коды состояния.Что подводит меня к следующей части моего ответа ...
Другие комментарии к вашему дизайну
Самый естественный способ интерпретации ответа 5xx на любой запросявляется то, что операция не удалась.
Таким образом, ответ 503 Service Unavailable на запрос GET /status означает, что сама операция проверки состояния завершилась неудачно.Такой ответ был бы полезен только в том случае, если мы можем быть уверены, что /status является конечным состоянием здоровья , как указано в проекте проверки работоспособности API , указанном в ответе Нкоси:
Конечная точка работоспособности имеет смысл только в контексте компонента, который указывает на работоспособность.У него нет другого значения или цели.Таким образом, его здоровье является проводником здоровья компонента.Клиенты ДОЛЖНЫ предположить, что код ответа HTTP, возвращаемый конечной точкой работоспособности, применим ко всему компоненту (например, более крупному API или микросервису).
Но при URL-пути всего /status не совсем очевидно, что на самом деле является конечной точкой работоспособности.Из просмотра URL мы знаем только то, что он возвращает информацию о статусе чего-либо, но мы не можем быть уверены, что это за «что-то».
Поскольку вы также говорите нам, что да, это на самом деле конечная точка здоровья, я должен предложить вам изменить имя на health.Я бы также предложил разместить его под некоторым базовым путем, например /things/health, чтобы было более понятно, какой компонент указывает на его работоспособность.
Если, с другой стороны, /status был фактически ресурсомон владеет, то есть чем-то, что представляет состояние некоторого другого компонента / предмета (как в настоящее время предлагает его название), тогда 200 OK является единственным разумным статусом для успешных вызовов, даже если то, что оно указывает настатус "Нездоровый".В этом случае 5xx будет означать, что статус не может быть получен, и предполагается, что детали в полезной нагрузке ответа связаны со сбоем в самой службе /status.
Так что будьте осторожны с тем, как вы называете вещи и какие коды состояния вы используете!