Каждый протокол, который мы используем сегодня, был определен и специфицирован в документе, который мы называем Request For Comments, или просто RFC. Коды состояния HTTP определены вместе с самим протоколом HTTP в RFC2616, документе, определяющем, что такое HTTP/1.1, а точнее, в разделе 10.
Они также определены в разделе 6 документа RFC7231, посвященном семантике HTTP/1.1. Они представляют собой числовой код, варьирующийся от 100 до 500, и призваны сделать ответ HTTP более значимым для клиента.
В этой статье мы узнаем немного больше о кодах состояния HTTP, о том, когда вебмастерам следует использовать каждый из них, и об их определениях.
Каждый раз, когда мы нажимаем на кнопку и посылаем запрос клиент-серверному приложению, это приложение отвечает нам другим HTTP-ответом, причем и запрос, и ответ содержат заголовок, который отвечает за то, чтобы передать нам контекст этого запроса.
Коды состояния содержатся в каждом ответе в заголовке под названием Status (как оригинально) и служат лишь для того, чтобы дать нам понять, что произошло с нашим запросом после его обработки.
Чаще всего обычные пользователи не видят этих кодов состояния - если только что-то не пошло совсем не так, - но для нас, программистов, они чрезвычайно ценны. Например, каждый раз, когда мы не можем найти ресурс или веб-страницу, нам выдается страница с ошибкой 404. 404 - это код статуса HTTP, означающий Not Found.
Короче говоря, они дают нам больше информации о том, что происходит и что случилось с запросом, который мы сделали, и они очень ценны для фронтендеров, которые хотят показывать правильные статусные сообщения в зависимости от того, что ответил сервер.
Классы кодов состояний HTTP
Как мы уже говорили, коды состояния HTTP нумеруются от 100 до 500, однако этот интервал заполнен не полностью, например, у нас нет кода состояния 174, поскольку это было сделано для разделения кодов на категории.
Эти категории определяются сотнями, каждая сотня интервала HTTP представляет собой отдельную категорию или класс:
• 100s: Это информационные коды, просто подтверждающие, что запрос получен и он обрабатывается;
• 200s: Коды успеха, возвращаются, когда все было обработано или понято правильно, как правило, это означает, что клиенту больше не нужно выполнять никаких действий;
• 300s: Коды перенаправления, означающие, что клиент должен запросить этот ресурс в другом месте;
• 400s: Коды ошибок клиента, когда клиент что-то напутал;
• 500s: Коды ошибок сервера, когда сервер что-то напутал.
Зачем знать коды состояния HTTP?
Коды состояния важны не только для программистов, поскольку нам необходимо знать, что происходит, чтобы выполнить валидацию или сообщить об ошибке, но и для мониторинга состояния нашего приложения, а также для SEO.
При мониторинге проще узнать о состоянии приложения по его коду состояния, например, если ваш сайт возвращает много 404, то, вероятно, кто-то напортачил и забыл выложить какую-то страницу в сеть, а если ваше приложение выдает много 500, то, скорее всего, оно находится в автономном режиме и никто не может им воспользоваться.
Поэтому команде разработчиков гораздо проще отлаживать приложение, когда оно отображает правильную информацию.
С другой стороны, когда мы говорим о SEO, коды состояния - это единственный способ, с помощью которого боты могут понять, что происходит, когда они "видят" ваш сайт.
Это означает, что если вы слепой робот, который понимает только коды состояния, то если страница постоянно возвращает код 404, это означает, что эта страница не очень хороша. Поскольку она не существует, поэтому ее рейтинг должен быть ниже, чем у других страниц, которые возвращают код состояния 200, поскольку они действительно существуют.
100 - Continue
Это один из очень распространенных кодов, но не так часто используемый, поскольку обычно он не посылается самим клиентом. На самом деле клиент ожидает код состояния 100, чтобы продолжить отправку запросов.
Когда его использовать:
Этот код используется в качестве ответа сервера, когда клиенты посылают частичные запросы, содержащие заголовок Expect: 100-continue. Этот заголовок указывает на то, что отправленный запрос содержит только заголовки для проверки, и после проверки заголовков запроса сервер должен вернуть код состояния 100, указывающий на то, что клиент теперь может отправлять тело запроса (в тех случаях, когда тело есть).
Если клиент получает код состояния 417, это означает, что сервер не может обработать заголовок Expect.
101 - Switching Protocols
Это подтверждение от сервера, указывающее на то, что он согласился с запросом клиента о переключении протоколов по заголовку Upgrade. Сервер должен ответить другим заголовком Upgrade, указывающим, на какую версию протокола он будет переключаться.
Когда использовать:
Только на стороне сервера, для клиентов малоприменимо.
200 - OK
Наверное, это самый распространенный код статуса из всех возвращаемых.
200 OK - это стандартный ответ на успешный запрос. Как правило, именно его мы и ожидаем увидеть. Однако ответ на этот код должен отличаться в зависимости от метода HTTP, как описано в RFC7231.
Когда его использовать:
Как правило, существует другой код состояния HTTP, который лучше выражает то, что вы хотите сказать, но если вы сомневаетесь, какой код HTTP использовать, а ваш ответ успешен, то 200 - это то, что нужно.
201 - Created
Этот код состояния обычно используется вместе с методом POST, поскольку описывает ресурс, который был создан на сервере после успешного выполнения запроса.
Когда его использовать:
При создании. Например, при создании нового пользователя в базе данных ответ должен быть 201 с только что созданным документом в качестве тела.
202 - Accepted
Это асинхронный код состояния, он констатирует, что запрос принят, но ничего не говорит ни о фактическом состоянии обработки этого запроса, ни о результате того, что может произойти на другом сервере.
Сервер должен предоставить в заголовке или любым другим способом указатель на монитор состояния, который будет представлять пользователю состояние запроса, отправленного ранее.
Когда использовать:
Это классическая ситуация "очереди", когда мы имеем ресурс, который должен быть поставлен в очередь для последующей обработки. Код состояния 202 означает, что ресурс принят, то есть с запросом все в порядке, но он не может быть обработан сейчас, но когда-нибудь будет завершен.
Это часто используется для пакетной обработки или каких-то операций, требующих больших затрат процессора: мы отправляем запрос, который должен быть обработан, а в ответ получаем ссылку на монитор состояния. Подобные API есть в Azure Cognitive Services.
203 - Non-Authoritative Information
Код 203 - это авторизованный man-in-the-middle, он говорит о том, что вышестоящий сервер за прокси-сервером вернул 200, но прокси-сервер изменил полезную нагрузку.
Когда использовать:
При использовании прокси-серверов этот код часто используется, когда при ответе на запрос прокси-сервер вводит дополнительную информацию.
204 – No Content
Это самый простой, но самый неиспользуемый код состояния. Он означает, что все в порядке, но сказать об этом нечего...
Когда его использовать:
Например, в запросах DELETE, поскольку такие запросы делают то, что должны делать, и ничего больше. Например, DELETE /user/1234 должен удалить пользователя, большинство возвращает код состояния 200, но этот код подразумевает, что придет какой-то ответ, в запросе DELETE это не так, нам больше нечего сказать по этому поводу, ресурс был просто... удален...
205 – Reset Content
Код 205 определен в RFC7231, и в нем говорится об одной из самых используемых вещей в прошлом - и в настоящем – постбеках. Синтезируя, он говорит, что запрос был обработан и пользователю следует запросить обновление страницы, чтобы увидеть это изменение.
Когда его использовать:
В SPA этот код сегодня канул в Лету, поскольку последнее, что делает SPA, - это обновляет страницу (ведь это одностраничное приложение...). Но иногда нам приходится иметь дело с 202 случаями, и мы могли бы иметь монитор состояния, который показывал бы нам, закончен процесс или нет. Если ресурс все еще обрабатывается, то он должен возвращать 202, в противном случае – 205.
206 – Partial Content
Это мой любимый код состояния, не только потому, что мы не так часто встречаем его и он так прост для понимания, но и потому, что он четко указывает, что он означает, и мог бы очень помочь, если бы его чаще использовали.
Код 206 означает, что содержимое, которое отправляется обратно, не является всем содержимым, имеющимся у сервера на данном ресурсе. Как вариант, это ответ на заголовок Range, отправленный клиентом. Azure Storage Services использует этот заголовок.
Когда его использовать:
Можно использовать его при выполнении поисковых запросов, например, запрос GET /users, это, очевидно, список пользователей, который я не могу вернуть полностью, поскольку он может занимать тонну байт, поэтому я разбиваю его на страницы.
В первый раз, когда пользователь запрашивает его, сервер отвечает на запрос 206 с пользовательским заголовком, который я люблю называть X-Content-Range и который содержит from-to/total, далее у нас есть два варианта:
• Пользователь запрашивает GET /users?page=2
• Пользователь запрашивает GET /users с заголовком Range: <номер страницы>.
Тогда сервер будет отвечать ему 206, пока не останется страниц, на последней странице он ответит 200, если пользователь попытается обратиться к странице, выходящей за пределы диапазона, я верну 204 (если не хочу вызывать панику) или 416.
300 - Multiple Choices
Код состояния multiple choices указывает на то, что целевой ресурс может быть найден более чем в одном URI или имеет более чем одно представление. Если запрос выполняется методом HEAD, то сервер должен вернуть заголовок Location, указывающий на местоположение предпочтительного ресурса.
В случае методов, отличных от HEAD, сервер должен передать вместе с кодом 300 полезную нагрузку, содержащую список всех представлений данного ресурса, чтобы клиент мог выбрать наиболее подходящее.
Когда использовать:
Обычно это используется на медиасерверах, где для одного и того же файла может быть несколько местоположений, например CDN, при запросе файла сервер API-шлюза может ответить статусом 300 и попросить выбрать из списка доступных местоположений.
Попробуем на примере сайта, запрашивающего изображение с CDN, клиент посылает GET-запрос на изображение, в ответ получает статус 300 и список доступных ресурсов, разделенных на регионы, после чего клиент может выбрать ближайший регион и получить изображение.
301 - Moved Permanently
Используется, когда искомый ресурс был навсегда перемещен в другое место. Этот код состояния обычно сопровождается другим заголовком, указывающим точное место, куда был перемещен ресурс.
Когда его использовать:
Обычно используется для постоянных перенаправлений с одного сайта на другой. Но загвоздка в том, что этот код состояния должен использоваться только для запросов типа GET или HEAD, для всех остальных методов следует использовать 308.
302 - Found
Несмотря на то, что текст "found" не дает нам особого представления о том, о чем идет речь, код состояния 302 обычно используется при временных перенаправлениях, сообщая о том, что ресурс был перемещен, но найден на другом URI, описанном в заголовке Location.
Когда его использовать:
В основном, то же самое, что и 301, но используется при временных переадресациях, когда ресурс в конечном итоге снова будет найден на текущем URL. Однако действует правило, что этот код состояния должен использоваться только с методами запроса GET или HEAD, для всех остальных методов следует использовать 307.
304 - Not Modified
Код состояния "не модифицирован" несколько сложен в силу своих возможностей, однако, согласно стандартной формулировке его определения, этот код состояния должен возвращаться, когда клиент выдает запрос с заголовками If-Modified-Since или If-None-Match и сервер не находит ни одного модифицированного ресурса.
Когда его использовать:
Как вариант. Можно возвращать код 304, если документ, измененный запросом PUT или PATCH, не претерпел никаких изменений, чаще всего это полезно для того, чтобы определить, следует ли перезагружать или нет страницу.
308 – Permanent Redirect
Этот код статуса определен в RFC7538, это тот же случай, что и 307, но вместо 302 он заменяет 301, вся остальная информация точно такая же.
Когда его использовать:
В тех же случаях, что и 301, но более строго.
403 - Forbidden
В отличие от 401, код состояния 403 относится к ресурсу, доступ к которому запрещен по любой другой причине, кроме авторизации, например, ограничение области видимости.
Когда его использовать:
Обычно используется, когда мы ограничиваем возможности пользователей в приложении, например, если я не являюсь администратором, то не должен иметь права удалять других пользователей, поэтому, если я попытаюсь это сделать, то получу ошибку 403 - Forbidden.
Правило заключается в том, чтобы запомнить следующую последовательность действий:
• Если я не знаю, кто делает запрос, то это 401 - Unauthorized.
• Если я знаю, кто делает запрос, но у пользователя нет на это прав, то это 403 – Forbidden
406 – Not Acceptable
Коды состояния 406 довольно просты. Они сообщают, что ресурс, запрошенный клиентом в формате заголовка Accept, недоступен в этом формате.
Когда его использовать:
Довольно часто встречается при использовании ReST, предположим, у нас есть API, который возвращает названия животных, мы можем получить эту информацию как в XML, так и в JSON, поэтому клиент должен указать в запросе заголовок Accept: application/xml или Accept: application/json, если клиент укажет Accept: image/jpeg, то мы вернем 406.
408 - Request Timeout
По коду 408 сервер принимает решение о закрытии открытого соединения из-за того, что клиенту потребовалось время на передачу полного запроса. Все серверы готовы принять и обработать запрос за определенное время, и если клиент не успевает отправить весь запрос за это время, сервер закрывает соединение.
Когда использовать:
Обычно это происходит автоматически, когда наш веб-сервер обнаруживает, что одно соединение было открыто слишком долго, обычно это происходит, когда мы загружаем большие файлы, которые занимают больше времени, чем сервер готов ждать.
410 - Gone
Gone - один из самых мощных кодов состояния HTTP, поскольку он явно указывает, что ресурс не только недоступен, но и не будет доступен в будущем. Это более мощный код, чем 404, поскольку он указывает поисковым системам на необходимость удаления данного ресурса из их индексов.
Когда использовать:
В основном используется при удалении ресурса, например, в большинстве случаев я использую логическое удаление, чтобы сохранить данные в базе данных, но колонка deletedAt не позволяет мне показывать их на странице, и если кто-то попытается получить доступ к этой записи, я могу вернуть 410.
412 - Precondition Failed
Указанный в RFC7232, код состояния 412 возвращается только в том случае, если сервер поддерживает If-Unmodified-Since или If-None-Match, а клиент посылает запрос, который не может удовлетворить этому условию.
Когда использовать:
Здесь не так много мест, куда можно пойти, в основном мы просто обращаемся к определению.
414 - Request-URI Too Long
Этот код состояния не появляется уже давно, поскольку большинство серверов сегодня могут обрабатывать огромное количество данных. Но код состояния 414 говорит о том, что запрошенный URI слишком длинный для сервера.
Когда его использовать:
Довольно просто, больше мы ничего не можем сделать.
416 - Request Range Not Satisfiable
Этот код определен в RFC7233 и гласит, что когда клиент посылает заголовок Range, выходящий за пределы доступного диапазона, который может обработать сервер, это должно быть ответом.
Когда его использовать:
Как мы видели в предыдущей статье, код состояния 416 может быть возвращен, если вы осуществляете пагинацию запроса и пользователь запрашивает страницу, выходящую за пределы максимального диапазона страниц.
418 - I'm a Teapot
Этот код даже не определен в RFC, поскольку не является официальным кодом состояния. Код 418 является частью апрельской шутки, в результате которой был создан новый протокол под названием Hyper Text Coffee Pot Control Protocol,
Когда его использовать:
Только для развлечения.
426 - Upgrade Required
Этот код указывает, что клиент должен обновить свою версию TLS до версии, указанной в заголовке Upgrade.
Когда использовать:
Обычно используется, когда серверы имеют определенные и строгие правила для протоколов безопасности, в таких случаях, когда протокол не принимается, он посылает обратно 426.
429 - Too many requests
Классический вариант "Вы пытаетесь меня DDoSить?". Код состояния 429 определен в другом RFC - RFC-6585 для дополнительных заголовков HTTP. Он указывает на то, что запросчик отправил слишком много запросов за определенный промежуток времени, что мы называем ограничением скорости.
Когда использовать:
Этот код должен использоваться по умолчанию всеми API, которые не хотят быть разрушенными DDoS-атаками, но поскольку сегодня это не так, наиболее распространенным вариантом использования этого кода состояния является ограничение количества запросов, которые может сделать пользователь, прежде чем он будет заблокирован сервером.
Большинство API-шлюзов и пользовательских API используют его, как, например, Twitter, который разрешает около 15 запросов в минуту.
451 - Unavailable For Legal Reasons
Этот код статуса является особенным, поскольку ему посвящен целый RFC. Опять же, и сообщение, и код очень понятны: ресурс недоступен по каким-то юридическим причинам.
Когда его использовать:
Этот код чаще всего используется на сайтах загрузки или в цифровых продуктах, где ресурс может быть отслежен до собственности, принадлежащей кому-либо, и эта собственность может стать недоступной по законной причине, скажем, книга незаконно загружена на сайт, если вы попытаетесь ее загрузить, то получите сообщение 451.
500 - Internal Server Error
Классическое "я что-то напутал". Этот код состояния отправляется в качестве ответа, когда сервер сделал что-то не так на своей стороне и не знает, как действовать дальше.
Если пользователь видит этот код, значит, с вашим приложением не все в порядке, поскольку эти коды состояния должны быть видны только внутренней стороне приложения. Пользовательская сторона должна отформатировать ошибку и показать более удобное для пользователя сообщение.
Когда использовать:
Когда исключение выброшено сервером и не поймано, и вы не знаете, что произошло, но знаете, что оно на сервере.
503 - Service Unavailable
Код 503 является скорее информационным, чем ошибочным, поскольку он сообщает, что сервер, обрабатывающий запросы, недоступен из-за перегрузки или планового обслуживания. В последнем случае сервер может дополнительно отправить заголовок Retry-After с указанием времени, в течение которого пользователь может повторить попытку.
Когда использовать:
Этот код обычно не устанавливается программистами, поскольку он находится в коде на стороне сервера, если только вы не являетесь разработчиком сервера, и в этом случае его использование вполне очевидно.
505 - HTTP Version Not Supported
Этот статусный код определен в последнем разделе RFC7231 как способ сообщить клиентам о необходимости обновления их протокола. По определению, он используется только для того, чтобы сообщить, что сервер не поддерживает основную версию HTTP, и тогда сервер ДОЛЖЕН послать сообщение, в котором говорится, почему эта версия не поддерживается и какие другие версии протокола он допускает.
Когда использовать:
Когда вы не принимаете запросы HTTP/1.1 или HTTP/1.0, а только HTTP/2.
Еще советуем:
