Код состояния HTTP для “успеха с ошибками”?
Я ввел по абсолютному адресу вокруг немного, но я не вижу код состояния HTTP для того, когда запрос успешно выполняется, но после "точки невозврата" существует ошибка.
например, Скажите, что Вы обрабатываете запрос, преданный база данных, но при возврате результата Вы выполнение памяти, или встречаетесь с NPE, или что имеет Вас. Это был бы a 200 ответ, но теперь, внутренне, Вы не можете возвратить надлежащий, правильно построенный ответ.
202 Accepted кажется, не соответствует, так как мы уже обработали запрос.
Какой код состояния означает "Успех, но ошибки"? Каждый даже существует?
3 ответа
Я согласен с @Daniel, что правильным ответом является HTTP 500 (ошибка сервера). Веб-приложение должно быть написано так, чтобы откатывать транзакцию при возникновении ошибки, а не оставлять дела незавершенными.
Одна вещь, которую вы можете использовать в своем веб-приложении, - это «идемпотентность». Это свойство функции (или операции), что вы можете повторять ее сколько угодно раз с тем же результатом. Например, если чтение не удается, клиент может просто повторять его, пока не завершится успешно. Если удаление кажется неудачным, клиент может снова повторить попытку, и сервер будет рассматривать запрос как действительный вне зависимости от того, исчез ли удаляемый ресурс. И если обновление кажется неудачным, клиент может повторить попытку, пока не получит успешный ответ от сервера. Подход REST к архитектуре веб-сервисов интенсивно использует идемпотентность, чтобы сделать операции устойчивыми перед лицом ошибок.
HTTP не имеет такого кода состояния, но есть лучшая практика, позволяющая обрабатывать такие ситуации - перенаправлять пользователя после операции POST.
Вот неисправность -
- Запрос POST пытается изменить данные на сервере
- Если сервер выходит из строя, он отправляет ошибку 500, чтобы указать на сбой
- Если сервер успешно, он отправляет 302 ответ перенаправления
- Затем браузер отправляет новый запрос GET на сервер
- Если это не удается, вы получаете ошибку 500, в противном случае вы получаете 200
Итак, ваш вариант использования «Сохраненные данные, но не могут» получить его немедленно »переводится в перенаправление 302 для начального POST, за которым следует 500 для последующего GET.
У этого подхода есть и другие преимущества - вы избавляетесь от надоедливого «Вы уверены, что хотите повторно отправить данные?» сообщение. Также позволяет использовать кнопки «назад / вперед / обновить».
Если сервер знает, что столкнулся с проблемой, он обычно должен возвращать ошибку 5xx. Наиболее распространенной является 500 Server Error, которую RFC 2616 определяет следующим образом:
500 Internal Server Error
Сервер столкнулся с неожиданным условием, которое не позволило ему выполнить запрос.
Тогда клиент обязан повторить попытку запроса. Если предыдущий запрос был частично зафиксирован, то сервер (или база данных) несет ответственность за откат этого запроса или за соответствующую обработку дублирующей транзакции.