Обработка кода ошибки REST API 500

мы создаем новый API REST.

Я утверждал, что код ошибки 500 (Внутренняя ошибка сервера) никогда не должен быть возвращен.

теперь, конечно, если вы знаете, что параметры клиента неправильны или что-то у вас есть все под контролем и может вернуть соответствующий код ошибки (например, 422).

поэтому, если произойдет непредвиденная ошибка, сервер может:

  1. не поймать неожиданные ошибки, так что 500 пузырьков до клиент
  2. поймать любые неожиданные ошибки и вернуть некоторый код ошибки, сигнализирующий о "неожиданной ситуации" (честно говоря, я не мог найти такой код ошибки!)

есть ли другие варианты?

5 ответов


Это ошибка сервера, а не ошибка клиента. Если бы ошибки сервера не возвращались клиенту, для них не был бы создан весь класс кода состояния (т. е. 5xx).

вы не можете скрыть тот факт, что вы либо сделали ошибку программирования, либо какая-то услуга, на которую вы полагаетесь, недоступна, и это, конечно, не вина клиента. Возврат любого другого диапазона кода в этих случаях, чем серия 5xx, не имеет смысла.

в RFC 7231 упоминает в раздел 6.6. Сервер кодом 5xx ошибка:

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

Это именно тот случай. В коде "500 Internal Server Error" нет ничего "внутреннего" в том смысле, что он не должен подвергаться воздействию клиента.


реальный вопрос заключается в том, почему он генерирует ошибку 500. Если это связано с любыми входными параметрами, то я бы сказал, что он должен быть обработан внутренне и возвращен как ошибка серии 400. Как правило, 400, 404 или 406 были бы уместны для отражения плохого ввода, поскольку общее соглашение заключается в том, что ресурс RESTful однозначно идентифицируется URL-адресом, а URL-адрес, который не может генерировать допустимый ответ, является плохим запросом (400) или подобным.

Если ошибка вызвана чем угодно кроме входов, явно или неявно предоставляемых запросом, я бы сказал, что ошибка 500, вероятно, подходит. Таким образом, неудачное подключение к базе данных или другая непредсказуемая ошибка точно представлена ошибкой серии 500.


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

угадайте, что: это то, для чего существует 5xx.


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

Да, некоторые веб-фреймворки будут отвечать кодами 5xx, но они обычно являются результатом дефектов в коде, и фреймворк слишком абстрактен, чтобы знать, что произошло, поэтому он по умолчанию этот пример, однако, не означает, что мы должны иметь привычку возвращать коды 5xx в результате программного поведения, которое не связано с системами вне процесса. Есть много, хорошо определенных кодов ответа, которые более подходят, чем коды 5xx. Неспособность проанализировать / проверить данный ввод не является ответом 5xx, потому что код может вместить более подходящий ответ, который не оставит клиента думать, что они могут повторно отправить тот же запрос, когда в на самом деле, они не могут.

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

вполне приемлемо, однако, уловить любые ошибки вне процесса и интерпретировать их как ответ 5xx, но имейте в виду, что вы также должны включить дополнительную информацию в ответ на укажите точно, что не удалось; и даже лучше, если вы можете включить время SLA для адреса.

Я не думаю, что это хорошая практика для интерпретации, "неожиданная ошибка" как ошибка 5xx, потому что происходят ошибки.

Это обычный монитор оповещений, чтобы начать оповещение о типах ошибок 5xx, потому что они обычно указывают на отказавшие системы, а не на отказавший код. Итак, код соответственно!


80 % раз, это было бы из-за неправильного ввода в soapRequest.в XML