Какие коды состояния HTTP вы фактически используете при разработке веб-приложений?

Ответ 1

Те, которые я использую (которые я мог бы найти с быстрым grep 'Status:' в любом случае):

• 200 Успешно извлечен ресурс, не затрагивая его
• 201 Отправляется всякий раз, когда представление формы помещает что-то существенное в базу данных (сообщение в форуме, учетная запись пользователя и т.д.), создавая новый ресурс
• 204 Отправлено с пустым телом, например, после DELETE
• 304 HTTP-кеширование. Я нашел, что это очень сложно, так как он должен учитывать пользователей, изменяющих настройки отображения и так далее. Лучшая идея, которую я придумал для этого, - использовать хэш пользовательских настроек как ETag. Это не помогает, что большинство браузеров имеют непредсказуемое и непоследовательное поведение здесь...
• 400 Используется для сообщений о неправильной форме, которые не позволяют проверить проверку.
• 403 Используется, когда кто-то где-то не должен (хотя я стараюсь избегать этого, не отображая ссылки на вещи, к которым пользователи не должны обращаться).
• 404 Помимо обычных веб-серверов я использую их, когда URL-адрес содержит недопустимые идентификационные номера. Я полагаю, было бы неплохо проверить в этом случае, существует ли более высокий действующий идентификатор и отправить 410 вместо этого...
• 429 Когда пользовательские запросы слишком часто посещаются
• 500. Я стараюсь помещать их в блоки catch {}, где единственный вариант - отказаться, чтобы в браузере было отправлено что-то значимое.

Я понимаю, что я мог уйти, просто позволив серверу отправить "200" на все, но они сохраняют большую боль, когда пользователи видят (или вызывают) ошибки и не сообщают вам о них. У меня уже есть функции для отображения сообщений, запрещенных к доступу, и так далее, поэтому не так много их добавить, чтобы добавить их.

Ответ 2

418: Я чайник

От http://www.ietf.org/rfc/rfc2324.txt Протокол управления потоком кофе в стиле гипертекста (HTCPCP/1.0)

Ответ 3

Не забывайте о 503 - Сервис недоступен. Это важно для простоя сайта. Особенно там, где поисковые системы.

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

Если вы просто показываете страницу "Временно вниз", но все равно возвращаете 200 OK, паук может индексировать страницы ошибок или, что еще хуже, заменить существующее индексирование этим "новым" контентом.

Это может серьезно повлиять на рейтинг вашего SEO, особенно если ваш большой популярный сайт.

Ответ 4

Я склонен использовать метод 405 не разрешен, если кто-то пытается получить URL-адрес, который может быть только POSTED. Кто-нибудь другой делает то же самое?

Ответ 5

303 See Other является обязательным для PRG, который вы должны использовать сейчас, если вы еще этого не сделали.

Ответ 6

Вот наиболее распространенные коды ответов, по моему опыту:

Коды ответов в диапазоне 1xx-2xx обычно обрабатываются автоматически базовым веб-сервером (то есть Apache, IIS), поэтому вам не нужно беспокоиться об этом.

Коды 301 и 302 обычно используются для перенаправления, а 304 используется много, когда клиент или прокси уже содержит действительную копию данных и не нуждается в новой версии с сервера (подробнее см. RFC как это работает).

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

Код 403 предназначен для выполнения аутентификации, которая обычно обычно обрабатывается несколько автоматически с помощью конфигурации сервера.

Код 404 - это код ошибки для страницы, которая не найдена.

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

Код 502 обычно просматривается, если вы проксируете с веб-сервера (например, Apache) на сервер приложений (например, Tomcat) в бэкэнд, а соединение не может быть выполнено на сервере приложений.

Для асинхронных вызовов (т.е. ответов AJAX/JSON) обычно безопаснее всегда возвращать ответ 200. Даже если при обработке запроса произошла ошибка на сервере, лучше всего включить ошибку в объект JSON и позволить клиенту справиться с этим. Причина в том, что не все веб-браузеры допускают доступ к телу ответа для не-200 ответных кодов.

Ответ 7

В Aida/Web мы используем только

• 200 Ok
• 302 Перенаправление
• 404 Не найдено
• 500 Внутренняя ошибка сервера

Ответ 8

В основном я использую их, где это необходимо. Сама спецификация определяет каждый код и обстоятельства, в которых они должны использоваться.

При создании веб-приложения RESTful я не рекомендую выбирать коды выбора и выбора и ограничивать себя подмножеством полного диапазона. То есть, если вы не создаете веб-приложение для конкретного HTTP-клиента - в этом случае на самом деле не создается веб-приложение, одно из которых создает приложение для этого конкретного клиента.

В моей фирме у нас есть клиенты Flex. Они не могут надлежащим образом обрабатывать коды статуса, отличные от 200, поэтому мы отправляем им специальный параметр с их запросами, который сообщает нашим серверам, что он всегда отправляет 200, даже если это не правильный ответ.

Ответ 9

У меня были кошмары о 500.

Ответ 10

500 Внутренняя ошибка сервера возвращается в Aida/Web, когда ваше веб-приложение вызывает исключение. Поскольку это приложение Smalltalk, на сервере создается окно исключения (если вы запустили его headfull), в то время как пользователь получил 500 и короткий стек.

На сервере вы можете открыть полный отладчик и попытаться решить проблему, в то время как сервер продолжает работать, конечно. Еще одна приятная вещь: окно с полным стеком ждет вас, пока вы не придете.

Заключение: 500 - это благословение, а не кошмар!

Ответ 11

Я использую 409 вместо 400 для плохих пользовательских данных (т.е. отправки формы).

Спецификации для 409 продолжаются о конфликтах версий, но в нем упоминается, что информация об устранении проблемы должна быть отправлена ​​в ответ. Идеально подходит для неправильных сообщений электронной почты или неправильных паролей.

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

Ответ 12

Я использую webmachine, который автоматически генерирует правильные коды ошибок. Но есть случаи, когда мне нужно поставлять свои собственные. Я нашел полезным для разработки и отладки, чтобы вернуть 666 в этих случаях, поэтому я могу легко сказать, какие из них поступают из моего кода, а какие - из webmachine. Кроме того, я получаю смешок от него, когда он появляется. Вы должны помнить, что нужно изменить это до развертывания для реального.