Должно ли это иметь значение, если вызов частного API REST возвращает 400 или 500?

Question

У нас есть закрытый REST API, который заблокирован и вызывается только программным обеспечением, которым мы управляем, а не publi c. Многие конечные точки занимают JSON полезную нагрузку. Если десериализация полезной нагрузки JSON не удалась (например, полезная нагрузка имеет int, где ожидается Guid), выдается исключение, и API возвращает 500 Internal Server Error. Технически, он должен возвратить 400 неверных запросов в этом случае.

Не зная, сколько усилий требуется для обеспечения возврата 400 в этом случае, есть ли польза в изменении API для возврата 400? Вызывающее программное обеспечение и QA - единственные объекты, которые видят эту ошибку, и это происходит только в том случае, если программное обеспечение отправляет данные, которые не соответствуют ожидаемой модели, которая в любом случае является критическим дефектом. Я рассматриваю это как дополнительное усилие и поддержание без выгоды.

Я что-то упускаю здесь, что различие между 400 и 500 могло бы значительно помочь?

Answer 1

С точки зрения REST:

1. Если вы хотите следовать строгим принципам REST, вы должны вернуть 4xx, поскольку проблема заключается в отправляемых данных, а не в программе сервера
2. 5xx зарезервированы для ошибок сервера. Например, если серверу не удалось выполнить метод из-за сбоя сайта или дефекта программного обеспечения. Коды состояния диапазона 5xx НЕ ДОЛЖНЫ использоваться для проверки или обработки логической ошибки.

С технической точки зрения:

1. Сообщенная ошибка не несет полезной информации, если завтра другой программист / team будет работать над проблемой
2. Если завтра вам придется занести свои ошибки в центральный журнал ошибок, вы будете загрязнять его ошибочными кодами состояния
3. Как следствие, если QA решит запустить отчеты / метрики об ошибках, они будут ошибочными
4. Возможно, вы увеличиваете свой технический долг, что может повлиять на вашу производительность в будущем. ссылка

Минимум, что вы можете сделать, это зарегистрировать эту проблему или создать заявку, если вы используете инструмент, подобный JIRA.

Answer 2

Должно ли это иметь значение, если вызов частного API REST возвращает 400 или 500?

Немного.

Код состояния это метаданные:

Элемент кода состояния представляет собой целочисленный код 3-ди git, описывающий результат попытки сервера понять и удовлетворить соответствующий запрос клиента. Остальная часть ответного сообщения должна интерпретироваться в свете семантики, определенной для этого кода состояния.

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

Основное различие между 4xx и 5xx - это общее направление проблемы. 4xx указывает на проблему в запросе, и косвенно с клиентом

Класс состояния кода 4xx (Ошибка клиента) указывает, что клиент, похоже, допустил ошибку.

5xx указывает на проблему на сервере.

Класс состояния кода 5xx (Ошибка сервера) указывает, что сервер знает, что он допустил ошибку или неспособен выполнить запрошенный метод

Итак, представьте, если хотите, обратный прокси общего назначения, действующий в качестве балансировщика нагрузки. Как прокси может воспользоваться возможностью различать 4xx и 5xx.

Хорошо ... 5xx предполагает, что сам запрос может быть в порядке. Таким образом, прокси-сервер может попытаться направить запрос к другому исправному экземпляру в кластере, чтобы проверить, доступен ли лучший ответ. Он может посмотреть на шаблон ответов 5xx от определенного c члена кластера и определить, является ли этот экземпляр здоровым или нездоровым. Затем он может выселить этот нездоровый экземпляр и обеспечить замену.

С другой стороны, с кодом состояния 4xx ни одно из этих мер не имеет никакого смысла - вместо этого мы знаем, что проблема с клиентом, и что перенаправление запроса в другой экземпляр не улучшит ситуацию.

Даже если вы не собираетесь автоматически уменьшать ошибки сервера, все равно может быть полезно различать два кода ошибки, для внутренние тревоги и отчеты.

(В системе, которую я поддерживаю, мы используем мониторинг общего назначения, который различает ответы 4xx и 5xx, с различными пороговыми значениями, чтобы определить, нужно ли мне пейджинговать. Как вы можете себе представить, я ' Я скорее вложил средства в то, чтобы эта система была хорошо настроена.)