Код статуса HTTP для «успеха с ошибками»? - PullRequest
9 голосов
/ 18 июня 2010

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

например, Скажитевы обрабатываете запрос, он передается в базу данных, но при возврате результата вы запускаете память, или обнаруживаете NPE, или что у вас есть.Это было бы ответом 200, но теперь внутренне вы не можете вернуть правильный, правильно сформированный ответ.

202 Accepted не похожеподходит, так как мы уже обработали запрос.

Какой код состояния означает «Успех, но ошибки»?Один вообще существует?

Ответы [ 3 ]

4 голосов
/ 18 июня 2010

HTTP не имеет такого кода состояния, но есть рекомендация, которая позволяет вам обрабатывать такие ситуации - перенаправить пользователя после операции POST.

Вот разбивка -

  1. POST-запрос пытается изменить данные на сервере
  2. Если сервер выходит из строя, он отправляет 500 ошибку, чтобы указать сбой
  3. Если сервер успешно работает, он отправляет ответ 302 перенаправления
  4. Затем браузер отправляет новый запрос GET на сервер
  5. Если это не удастся, вы получите ошибку 500, в противном случае вы получите 200

Итак, ваш вариант использования «Сохраненные данные, но вы не можете получить их немедленно» преобразуется в редирект 302 для начального POST, затем 500 для последующего GET.

У этого подхода есть и другие преимущества: вы избавляетесь от раздражающего «Вы уверены, что хотите повторно отправить данные?» сообщение. Также позволяет использовать кнопки «назад», «вперед» и «обновить».

3 голосов
/ 18 июня 2010

Если сервер знает, что он столкнулся с проблемой, он обычно возвращает ошибку 5xx.Наиболее общим является 500 Server Error, который RFC 2616 определяет следующим образом:

500 Внутренняя ошибка сервера

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

Тогда ответственность за повторную попытку запроса лежит на клиенте.Если предыдущий запрос был частично зафиксирован, то сервер (или база данных) несет ответственность за его откат или надлежащую обработку дублированной транзакции.

1 голос
/ 18 июня 2010

Я согласен с @Daniel, что правильный ответ - HTTP 500 (ошибка сервера). Веб-приложение должно быть написано для отката транзакции при возникновении ошибки, а не для того, чтобы все оставалось незавершенным.

Одна вещь, которую вы можете использовать в своем веб-приложении, это «идемпотентность». Это свойство функции (или операции), которую вы можете повторять столько раз, сколько хотите, с одним и тем же результатом. Например, если чтение не удалось, клиент может просто повторить его, пока оно не будет успешно выполнено. Если удаление кажется неудачным, клиент может снова повторить попытку, и сервер обработает запрос как действительный, независимо от того, удален ли уже удаленный ресурс. И если обновление кажется неудачным, клиент может повторить это, пока не получит успешный возврат с сервера. Подход REST к архитектуре веб-сервисов активно использует идемпотентность, чтобы сделать операции устойчивыми к ошибкам.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...