Код ошибки 401 api - Не ошибается лишь тот, кто ничего не делает!

REST API использует строку состояния в HTTP ответе (статус ответа), чтобы информировать Клиентов о результате запроса.

Вообще HTTP определяет 40 стандартных кодов состояния (статусов ответа), которые делятся на пять категорий. Ниже выделены только те коды состояния, которые часто используются в REST API.

Категория	Описание
1xx: Информация	В этот класс содержит заголовки информирующие о процессе передачи. Это обычно предварительный ответ, состоящий только из Status-Line и опциональных заголовков, и завершается пустой строкой. Нет обязательных заголовков. Серверы НЕ ДОЛЖНЫ посылать 1xx ответы HTTP/1.0 клиентам.
2xx: Успех	Этот класс кодов состояния указывает, что запрос клиента был успешно получен, понят, и принят.
3xx: Перенаправление	Коды этого класса сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос, как правило, по другому URI. Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям.
4xx: Ошибка клиента	Класс кодов 4xx предназначен для указания ошибок со стороны клиента.
5xx: Ошибка сервера	Коды ответов, начинающиеся с «5» указывают на случаи, когда сервер знает, что произошла ошибка или он не может обработать запрос.

Коды состояний в REST

Звездочкой * помечены популярные (часто используемые) коды ответов.

200 * (OK)

Запрос выполнен успешно. Информация, возвращаемая с ответом зависит от метода, используемого в запросе, например при:

GET Получен объект, соответствующий запрошенному ресурсу.
HEAD Получены поля заголовков, соответствующие запрошенному ресурсу, тело ответа пустое.
POST Запрошенное действие выполнено.

201 * (Created — Создано)

REST API отвечает кодом состояния 201 при каждом создании ресурса в коллекции. Также могут быть случаи, когда новый ресурс создается в результате какого-либо действия контроллера, и в этом случае 201 также будет подходящем ответом.

Ссылка (URL) на новый ресурс может быть в теле ответа или в поле заголовка ответа Location.

Сервер должен создать ресурс перед тем как вернуть 201 статус. Если это невозможно сделать сразу, тогда сервер должен ответить кодом 202 (Accepted).

202 (Accepted — Принято)

Ответ 202 обычно используется для действий, которые занимают много времени для обработки и не могут быть выполнены сразу. Это означает, что запрос принят к обработке, но обработка не завершена.

Его цель состоит в том, чтобы позволить серверу принять запрос на какой-либо другой процесс (возможно, пакетный процесс, который выполняется только один раз в день), не требуя, чтобы соединение агента пользователя с сервером сохранялось до тех пор, пока процесс не будет завершен.

Сущность, возвращаемая с этим ответом, должна содержать указание на текущее состояние запроса и указатель на монитор состояния (расположение очереди заданий) или некоторую оценку того, когда пользователь может ожидать выполнения запроса.

203 (Non-Authoritative Information — Неавторитетная информация)

Предоставленная информация взята не из оригинального источника (а, например, из кэша, который мог устареть, или из резервной копии, которая могла потерять актуальность). Этот факт отражен в заголовке ответа и подтверждается этим кодом. Предоставленная информация может совпадать, а может и не совпадать с оригинальными данными.

204 * (No Content — Нет контента)

Код состояния 204 обычно отправляется в ответ на запрос PUT, POST или DELETE, когда REST API отказывается отправлять обратно любое сообщение о состоянии проделанной работы.

API может также отправить 204 статус в ответ на GET запрос, чтобы указать, что запрошенный ресурс существует, но не имеет данных для добавления их в тело ответа.

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

205 — (Reset Content — Сброшенное содержимое)

Сервер успешно обработал запрос и обязывает клиента сбросить введенные пользователем данные. В ответе не должно передаваться никаких данных (в теле ответа). Обычно применяется для возврата в начальное состояние формы ввода данных на клиенте.

206 — (Partial Content — Частичное содержимое)

Сервер выполнил часть GET запроса ресурса. Запрос ДОЛЖЕН был содержать поле заголовка Range (секция 14.35), который указывает на желаемый диапазон и МОГ содержать поле заголовка If-Range (секция 14.27), который делает запрос условным.

Запрос ДОЛЖЕН содержать следующие поля заголовка:

Либо поле Content-Range (секция 14.16), который показывает диапазон, включённый в этот запрос, либо Content-Type со значением multipart/byteranges, включающими в себя поля Content-Range для каждой части. Если в заголовке запроса есть поле Content-Length, его значение ДОЛЖНО совпадать с фактическим количеством октетов, переданных в теле сообщения.
Date
ETag и/или Content-Location, если ранее был получен ответ 200 на такой же запрос.
Expires, Cache-Control, и/или Vary, если значение поля изменилось с момента отправления последнего такого же запроса

Если ответ 206 — это результат выполнения условного запроса, который использовал строгий кэш-валидатор (подробнее в секции 13.3.3), в ответ НЕ СЛЕДУЕТ включать какие-либо другие заголовки сущности. Если такой ответ — результат выполнения запроса If-Range, который использовал «слабый» валидатор, то ответ НЕ ДОЛЖЕН содержать другие заголовки сущности; это предотвращает несоответствие между закэшированными телами сущностей и обновлёнными заголовками. В противном случае ответ ДОЛЖЕН содержать все заголовки сущностей, которые вернули статус 200 (OK) на тот же запрос.

Кэш НЕ ДОЛЖЕН объединять ответ 206 с другими ранее закэшированными данными, если поле ETag или Last-Modified в точности не совпадают (подробнее в секции 16.5.4)

Кэш, который не поддерживает заголовки Range и Content-Range НЕ ДОЛЖЕН кэшировать ответы 206 (Partial).

300 — (Multiple Choices — Несколько вариантов)

По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю.

Если это не запрос HEAD, ответ ДОЛЖЕН включать объект, содержащий список характеристик и адресов, из которого пользователь или агент пользователя может выбрать один наиболее подходящий. Формат объекта определяется по типу данных приведённых в Content-Type поля заголовка. В зависимости от формата и возможностей агента пользователя, выбор наиболее подходящего варианта может выполняться автоматически. Однако эта спецификация не определяет никакого стандарта для автоматического выбора.

Если у сервера есть предпочтительный выбор представления, он ДОЛЖЕН включить конкретный URI для этого представления в поле Location; агент пользователя МОЖЕТ использовать заголовок Location для автоматического перенаправления к предложенному ресурсу. Этот запрос может быть закэширован, если явно не было указано иного.

301 (Moved Permanently — Перемещено навсегда)

Код перенаправления. Указывает, что модель ресурсов REST API была сильно изменена и теперь имеет новый URL. Rest API должен указать новый URI в заголовке ответа Location, и все будущие запросы должны быть направлены на указанный URI.

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

302 (Found — Найдено)

Является распространенным способом выполнить перенаправление на другой URL. HTTP-ответ с этим кодом должен дополнительно предоставит URL-адрес куда перенаправлять в поле заголовка Location. Агенту пользователя (например, браузеру) предлагается в ответе с этим кодом сделать второй запрос на новый URL.

Многие браузеры реализовали этот код таким образом, что нарушили стандарт. Они начали изменять Тип исходного запроса, например с POST на GET. Коды состояния 303 и 307 были добавлены для серверов, которые хотят однозначно определить, какая реакция ожидается от клиента.

303 (See Other — Смотрите другое)

Ответ 303 указывает, что ресурс контроллера завершил свою работу, но вместо отправки нежелательного тела ответа он отправляет клиенту URI ресурса. Это может быть URI временного сообщения о состоянии ресурса или URI для уже существующего постоянного ресурса.

Код состояния 303 позволяет REST API указать ссылку на ресурс, не заставляя клиента загружать ответ. Вместо этого клиент может отправить GET запрос на URL указанный в заголовке Location.

Ответ 303 не должен кэшироваться, но ответ на второй (перенаправленный) запрос может быть кэшируемым.

304 * (Not Modified — Не изменен)

Этот код состояния похож на 204 (Нет контента), так как тело ответа должно быть пустым. Ключевое различие состоит в том, что 204 используется, когда нет ничего для отправки в теле, тогда как 304 используется, когда ресурс не был изменен с версии, указанной заголовками запроса If-Modified-Since или If-None-Match.

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

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

305 — (Use Proxy — Используйте прокси)

Доступ к запрошенному ресурсу ДОЛЖЕН быть осуществлен через прокси-сервер, указанный в поле Location. Поле Location предоставляет URI прокси. Ожидается, что получатель повторит этот запрос с помощью прокси. Ответ 305 может генерироваться ТОЛЬКО серверами-источниками.

Заметьте: в спецификации RFC 2068 однозначно не сказано, что ответ 305 предназначен для перенаправления единственного запроса, и что он должен генерироваться только сервером-источником. Упущение этих ограничений вызвало ряд значительных последствий для безопасности.

Многие HTTP клиенты (такие, как Mozilla и Internet Explorer) обрабатывают этот статус некорректно прежде всего из соображений безопасности.

307 (Temporary Redirect — Временный редирект)

Ответ 307 указывает, что rest API не будет обрабатывать запрос клиента. Вместо этого клиент должен повторно отправить запрос на URL, указанный в заголовке Location. Однако в будущих запросах клиент по-прежнему должен использоваться исходный URL.

Rest API может использовать этот код состояния для назначения временного URL запрашиваемому ресурсу.

Если метод запроса не HEAD, тело ответа должно содержать короткую заметку с гиперссылкой на новый URL. Если код 307 был получен в ответ на запрос, отличный от GET или HEAD, Клиент не должен автоматически перенаправлять запрос, если он не может быть подтвержден Клиентом, так как это может изменить условия, при которых был создан запрос.

308 — (Permanent Redirect — Постоянное перенаправление) (experimental)

Нужно повторить запрос на другой адрес без изменения применяемого метода.

Этот и все последующие запросы нужно повторить на другой URI. 307 и 308 (как предложено) Схож в поведении с 302 и 301, но не требуют замены HTTP метода. Таким образом, например, отправку формы на «постоянно перенаправленный» ресурс можно продолжать без проблем.

400 * (Bad Request — Плохой запрос)

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

Клиент не должен повторять точно такой же запрос.

401 * (Unauthorized — Неавторизован)

401 сообщение об ошибке указывает, что клиент пытается работать с закрытым ресурсом без предоставления данных авторизации. Возможно, он предоставил неправильные учетные данные или вообще ничего. Ответ должен включать поле заголовка WWW-Authenticate, содержащего описание проблемы.

Клиент может повторить запрос указав в заголовке подходящее поле авторизации. Если это уже было сделано, то в ответе 401 будет указано, что авторизация для указанных учетных данных не работает. Если в ответе 401 содержится та же проблема, что и в предыдущем ответе, и Клиент уже предпринял хотя бы одну попытку проверки подлинности, то пользователю Клиента следует представить данные полученные в ответе, владельцу сайта, так как они могут помочь в диагностике проблемы.

402 — (Payment Required — Требуется оплата)

Этот код зарезервирован для использования в будущем.

Предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

403 * (Forbidden — Запрещено)

Ошибка 403 указывает, что rest API отказывается выполнять запрос клиента, т.е. Клиент не имеет необходимых разрешений для доступа. Ответ 403 не является случаем, когда нужна авторизация (для ошибки авторизации используется код 401).

Попытка аутентификация не поможет, и повторные запросы не имеют смысла.

404 * (Not Found — Не найдено)

Указывает, что rest API не может сопоставить URL клиента с ресурсом, но этот URL может быть доступен в будущем. Последующие запросы клиента допустимы.

404 не указывает, является ли состояние временным или постоянным. Для указания постоянного состояния используется код 410 (Gone — Пропал). 410 использоваться, если сервер знает, что старый ресурс постоянно недоступен и более не имеет адреса.

405 (Method Not Allowed — Метод не разрешен)

API выдает ошибку 405, когда клиент пытался использовать HTTP метод, который недопустим для ресурса. Например, указан метод PUT, но такого метода у ресурса нет.

Ответ 405 должен включать Заголовок Allow, в котором перечислены поддерживаемые HTTP методы, например, Allow: GET, POST.

406 (Not Acceptable — Неприемлемый)

API не может генерировать предпочитаемые клиентом типы данных, которые указаны в заголовке запроса Accept. Например, запрос клиента на данные в формате application/xml получит ответ 406, если API умеет отдавать данные только в формате application/json.

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

407 — (Proxy Authentication Required — Требуется прокси-аутентификация)

Ответ аналогичен коду 401, за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере.

Пользователь должен сначала авторизоваться через прокси. Прокси-сервер должен вернуть Proxy-Authenticate заголовок, содержащий запрос ресурса. Клиент может повторить запрос вместе с Proxy-Authenticate заголовком. Появился в HTTP/1.1.

408 — (Request Timeout — Таймаут запроса)

Время ожидания сервером передачи от клиента истекло. Клиент не предоставил запрос за то время, пока сервер был готов его принят. Клиент МОЖЕТ повторить запрос без изменений в любое время.

Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потери связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос.

409 * (Conflict — Конфликт)

Запрос нельзя обработать из-за конфликта в текущем состоянии ресурса. Этот код разрешается использовать только в тех случаях, когда ожидается, что пользователь может самостоятельно разрешить этот конфликт и повторить запрос. В тело ответа СЛЕДУЕТ включить достаточное количество информации для того, чтобы пользователь смог понять причину конфликта. В идеале ответ должен содержать такую информацию, которая поможет пользователю или его агенту исправить проблему. Однако это не всегда возможно и это не обязательно.

Как правило, конфликты происходят во время PUT-запроса. Например, во время использования версионирования, если сущность, к которой обращаются методом PUT, содержит изменения, конфликтующие с теми, что были сделаны ранее третьей стороной, серверу следует использовать ответ 409, чтобы дать понять пользователю, что этот запрос нельзя завершить. В этом случае в ответной сущности должен содержаться список изменений между двумя версиями в формате, который указан в поле заголовка Content-Type.

410 — (Gone — Исчез)

Такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии. Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404. Появился в HTTP/1.1.

411 — (Length Required — Требуется длина)

Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение.

412 — (Precondition Failed — Предварительное условие не выполнено)

Возвращается, если ни одно из условных полей заголовка запроса не было выполнено.

Когда клиент указывает rest API выполнять запрос только при выполнении определенных условий, а API не может выполнить запрос при таких условиях, то возвращается ответ 412.

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

413 — (Request Entity Too Large — Сущность запроса слишком большая)

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

Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос.

414 — (Request-URI Too Long — Запрос-URI Слишком длинный)

Сервер не может обработать запрос из-за слишком длинного указанного URL. Эту редкую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST, когда клиент попадает в «чёрную дыру» перенаправлений (например, когда префикс URI указывает на своё же окончание), или когда сервер подвергается атаке со стороны клиента, который пытается использовать дыры в безопасности, которые встречаются на серверах с фиксированной длиной буфера для чтения или обработки Request-URI.

415 (Unsupported Media Type — Неподдерживаемый медиа тип)

Сообщение об ошибке 415 указывает, что API не может обработать предоставленный клиентом Тип медиа, как указано в заголовке запроса Content-Type.

Например, запрос клиента содержит данные в формате application/xml, а API готов обработать только application/json. В этом случае клиент получит ответ 415.

Например, клиент загружает изображение как image/svg+xml, но сервер требует, чтобы изображения использовали другой формат.

428 — (Precondition Required — Требуется предварительное условие)

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

Его типичное использование — избежать проблемы «потерянного обновления», когда клиент ПОЛУЧАЕТ состояние ресурса, изменяет его и ОТПРАВЛЯЕТ обратно на сервер, когда тем временем третья сторона изменила состояние на сервере, что привело к конфликту. Требуя, чтобы запросы были условными, сервер может гарантировать, что клиенты работают с правильными копиями.

Ответы с этим кодом состояния ДОЛЖНЫ объяснять, как повторно отправить запрос.

429 — (Too Many Requests — Слишком много запросов)

Пользователь отправил слишком много запросов за заданный промежуток времени.

Представления ответа ДОЛЖНЫ включать подробности, объясняющие условие, и МОГУТ включать заголовок Retry-After, указывающий, как долго ждать, прежде чем делать новый запрос.

431 — (Request Header Fields Too Large — Слишком большие поля заголовка запроса)

Код состояния 431 указывает на то, что сервер не желает обрабатывать запрос, поскольку его поля заголовка слишком велики. Запрос МОЖЕТ быть отправлен повторно после уменьшения размера полей заголовка запроса.

Его можно использовать как в случае, когда совокупность полей заголовка запроса слишком велика, так и в случае неисправности одного поля заголовка. В последнем случае представление ответа ДОЛЖНО указывать, какое поле заголовка было слишком большим.

444 — (No Response — Нет ответа) (Nginx)

Код ответа Nginx. Сервер не вернул информацию и закрыл соединение. (полезно в качестве сдерживающего фактора для вредоносных программ)

451 — (Unavailable For Legal Reasons — Недоступен по юридическим причинам)

Доступ к ресурсу закрыт по юридическим причинам. Наиболее близким из существующих является код 403 Forbidden (сервер понял запрос, но отказывается его обработать). Однако в случае цензуры, особенно когда это требование к провайдерам заблокировать доступ к сайту, сервер никак не мог понять запроса — он его даже не получил. Совершенно точно подходит другой код: 305 Use Proxy. Однако такое использование этого кода может не понравиться цензорам. Было предложено несколько вариантов для нового кода, включая «112 Emergency. Censorship in action» и «460 Blocked by Repressive Regime»

500 * (Internal Server Error — Внутренняя ошибка сервера)

Общий ответ при ошибке в коде. Универсальное сообщение о внутренней ошибке сервера, когда никакое более определенное сообщение не подходит.

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

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

501 (Not Implemented — Не реализован)

Серверу либо неизвестен метод запроса, или ему (серверу) не хватает возможностей выполнить запрос. Обычно это подразумевает будущую доступность (например, новая функция API веб-сервиса).

Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405.

502 — (Bad Gateway — Плохой шлюз)

Сервер, выступая в роли шлюза или прокси-сервера, получил некорректный ответ от вышестоящего сервера, к которому он обратился. Появился в HTTP/1.0.

503 — (Service Unavailable — Служба недоступна)

Сервер не может обработать запрос из-за временной перегрузки или технических работ. Это временное состояние, из которого сервер выйдет через какое-то время. Если это время известно, то его МОЖНО передать в заголовке Retry-After.

504 — (Gateway Timeout — Таймаут шлюза)

Сервер, в роли шлюза или прокси-сервера, не дождался в рамках установленного таймаута ответа от вышестоящего сервера текущего запроса.

505 — (HTTP Version Not Supported — Версия HTTP не поддерживается)

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

510 — (Not Extended — Не расширен)

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

—

Источники и более подробная информация:

https://restapitutorial.ru/httpstatuscodes.html
https://www.restapitutorial.com/httpstatuscodes.html
https://restfulapi.net/http-status-codes/
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/428

Источник

Появление сообщения об ошибке 401 Unauthorized Error («отказ в доступе») при открытии страницы сайта означает неверную авторизацию или аутентификацию пользователя на стороне сервера при обращении к определенному url-адресу. Чаще всего она возникает при ошибочном вводе имени и/или пароля посетителем ресурса при входе в свой аккаунт. Другой причиной являются неправильные настройки, допущенные при администрировании web-ресурса. Данная ошибка отображается в браузере в виде отдельной страницы с соответствующим описанием. Некоторые разработчики интернет-ресурсов, в особенности крупных порталов, вводят собственную дополнительную кодировку данного сбоя:

401 Unauthorized;
Authorization Required;
HTTP Error 401 – Ошибка авторизации.

Попробуем разобраться с наиболее распространенными причинами возникновения данной ошибки кода HTTP-соединения и обсудим способы их решения.

Причины появления ошибки сервера 401 и способы ее устранения на стороне пользователя

При доступе к некоторым сайтам (или отдельным страницам этих сайтов), посетитель должен пройти определенные этапы получения прав:

Идентификация – получение вашей учетной записи («identity») по username/login или email.
Аутентификация («authentic») – проверка того, что вы знаете пароль от этой учетной записи.
Авторизация – проверка вашей роли (статуса) в системе и решение о предоставлении доступа к запрошенной странице или ресурсу на определенных условиях.

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

Наиболее распространенной причиной появления ошибки с кодом 401 для рядового пользователя является ввод неверных данных при посещении определенного ресурса. В этом и других случаях нужно попробовать сделать следующее:

Проверьте в адресной строке правильность написания URL. Особенно это касается перехода на подстраницы сайта, требующие авторизации. Введите правильный адрес. Если переход на страницу осуществлялся после входа в аккаунт, разлогинитесь, вернитесь на главную страницу и произведите повторный вход с правильными учетными данными.
При осуществлении входа с сохраненными данными пользователя и появлении ошибки сервера 401 проверьте их корректность в соответствующих настройках данного браузера. Возможно, авторизационные данные были вами изменены в другом браузере. Также можно очистить кэш, удалить cookies и повторить попытку входа. При удалении истории браузера или очистке кэша потребуется ручное введение логина и пароля для получения доступа. Если вы не помните пароль, пройдите процедуру восстановления, следуя инструкциям.
Если вы считаете, что вводите правильные регистрационные данные, но не можете получить доступ к сайту, обратитесь к администратору ресурса. В этом случае лучше всего сделать скриншот проблемной страницы.
Иногда блокировка происходит на стороне провайдера, что тоже приводит к отказу в доступе и появлению сообщения с кодировкой 401. Для проверки можно попробовать авторизоваться на том же ресурсе с альтернативного ip-адреса (например, используя VPN). При подтверждении блокировки трафика свяжитесь с провайдером и следуйте его инструкциям.

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

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

Устранение ошибки 401 администратором веб-ресурса

Для владельцев сайтов, столкнувшихся с появлением ошибки отказа доступа 401, решить ее порою намного сложнее, чем обычному посетителю ресурса. Есть несколько рекомендаций, которые помогут в этом:

Обращение в службу поддержки хостинга сайта. Как и в случае возникновения проблем с провайдером, лучше всего подробно описать последовательность действий, приведших к появлению ошибки 401, приложить скриншот.
При отсутствии проблем на стороне хостинг-провайдера можно внести следующие изменения в настройки сайта с помощью строки Disallow:/адрес проблемной страницы. Запретить индексацию страницам с ошибкой в «rоbоts.txt», после чего добавить в файл «.htассеss» строку такого типа:

Redirect 301 /oldpage.html http://site.com/newpage.html.

Где в поле /oldpage.html прописывается адрес проблемной страницы, а в http://site.com/newpage.html адрес страницы авторизации.

Таким образом вы перенаправите пользователей со всех страниц, которые выдают ошибку 401, на страницу начальной авторизации.

Если после выполнения предыдущих рекомендаций пользователи при попытках авторизации все равно видят ошибку 401, то найдите на сервере файл «php.ini» и увеличьте время жизни сессии, изменив значения следующих параметров: «session.gc_maxlifetime» и «session.cookie_lifetime» на 1440 и 0 соответственно.
Разработчики веб-ресурсов могут использовать более сложные методы авторизации и аутентификации доступа для создания дополнительной защиты по протоколу HTTP. Если устранить сбой простыми методами администрирования не удается, следует обратиться к специалистам, создававшим сайт, для внесения соответствующих изменений в код.

Хотя ошибка 401 и является проблемой на стороне клиента, ошибка пользователя на стороне сервера может привести к ложному требованию входа в систему. К примеру, сетевой администратор разрешит аутентификацию входа в систему всем пользователям, даже если это не требуется. В таком случае сообщение о несанкционированном доступе будет отображаться для всех, кто посещает сайт. Баг устраняется внесением соответствующих изменений в настройки.

Дополнительная информация об ошибке с кодом 401

Веб-серверы под управлением Microsoft IIS могут предоставить дополнительные данные об ошибке 401 Unauthorized в виде второго ряда цифр:

401, 1 – войти не удалось;
401, 2 – ошибка входа в систему из-за конфигурации сервера;
401, 3 – несанкционированный доступ из-за ACL на ресурс;
401, 501 – доступ запрещен: слишком много запросов с одного и того же клиентского IP; ограничение динамического IP-адреса – достигнут предел одновременных запросов и т.д.

Более подробную информацию об ошибке сервера 401 при использовании обычной проверки подлинности для подключения к веб-узлу, который размещен в службе MS IIS, смотрите здесь.

Следующие сообщения также являются ошибками на стороне клиента и относятся к 401 ошибке:

400 Bad Request;
403 Forbidden;
404 Not Found;
408 Request Timeout.

Как видим, появление ошибки авторизации 401 Unauthorized не является критичным для рядового посетителя сайта и чаще всего устраняется самыми простыми способами. В более сложной ситуации оказываются администраторы и владельцы интернет-ресурсов, но и они в 100% случаев разберутся с данным багом путем изменения настроек или корректировки html-кода с привлечением разработчика сайта.

Источник

Error description
Short error description in the response
Example of an error message

If an error occurs, the request processing stops, and the server returns an HTTP response code that identifies the error. In addition to the code, the response contains a short error description.

The error message is returned in the format specified in the request URL after the method name or in the Accept HTTP header.

The error description is passed in the error parameter. This parameter contains the error code (the code parameter) and a short error description (the message parameter).

Code	Name	Explanation
200	OK	The request is successfully completed.
206	Partial Content	The request is partially completed.
400	Bad Request	The request is invalid.
401	Unauthorized	The request doesn’t include authorization data.
403	Forbidden	Incorrect authorization data is specified in the request, or access to the requested resource is denied.
404	Not Found	The requested resource isn’t found.
405	Method Not Allowed	The requested method isn’t supported for the specified resource.
415	Unsupported Media Type	The requested content type isn’t supported by the method.
420	Enhance Your Calm	The resource access restriction is exceeded.
500	Internal Server Error	Internal server error. Try calling the method after a while. If the error persists, contact the Yandex.Market support service.
503	Service Unavailable	The server is temporarily unavailable due to high load. Try calling the method after a while.

For the 400 Bad Request error:

Description	Explanation	Possible solution
`Collection of field must not be empty`	The parameter must not be empty.	Specify at least one element for the parameter.
`Invalid status: 'status'`	Invalid status is specified.	Check if the sent status is correct for order filtering by status.
`JSON: {message}`	The JSON data format contains an error.	Check if the data passed in the request body has the correct JSON format.
`Missing field`	The required parameter isn’t specified.	Specify a value for the required parameter.
`The request is too big`	The HTTP request size limit is exceeded.	Cut the request size by reducing the amount of the sent data.
`Too long time period. Maximum is 'maxPeriod' days`	The specified date range is too large. Maximum range — maxPeriod.	Reduce the date range to filter orders by date.
`Unexpected character 'character': expected a valid value 'values'`	Invalid character.	Check the request body encoding. The required encoding is UTF-8.
`Unexpected end of content`	The request body ends unexpectedly.	Check if the data passed in the request body has the correct format.
`Value / length of field (value) must be between min and max [exclusively]`	The parameter value (length) must be between the min and max values and not equal to them.	Check if the parameter value is correct.
`Value / length of field (value) must be greater / less than [or equal to] limit`	The parameter value (length) must be equal to or greater than (less than) the specified limit value.	Check if the parameter value is correct.
`Value of field has too high scale: 'price'`	The accuracy of the parameter is set too high.	Set the parameter values with less precision.
`Value of field must match the pattern: 'regExp'`	The parameter value must match the regular expression.	Check if the parameter value is correct.
`XML: {message}`	The XML data format contains an error.	Check if the data passed in the request body has the correct XML format.

Other short descriptions that can be found in messages about this error are provided in the descriptions of the corresponding resources.

For the 401 Unauthorized error:

Description	Explanation	Possible solution
`Unsupported authorization type specified in Authorization header`	Authorization type passed in the Authorization HTTP header isn’t supported.	Check if the authorization data is correct.
`Authorization header has invalid syntax`	The Authorization HTTP header format is incorrect.	Check if the authorization data is correct.
`OAuth credentials are not specified`	The request doesn’t include authorization data.	Check that the authorization data is correct.
`OAuth token is not specified`	The request doesn’t include the authorization token (the oauth_token parameter).	Check if the authorization data is correct.
`OAuth client id is not specified`	The request doesn’t include the application ID (the oauth_client_id parameter).	Check if the authorization data is correct.

For the 403 Forbidden error:

Description	Explanation	Possible solution
`Access denied`	Access to the specified resource is prohibited.	Check if the resource is specified correctly, and if the authorized user login has access to it.
`Access to API denied for the client / campaign`	The client or store isn’t allowed to access the Yandex.Market Partner API.	Agency clients should contact their agency about getting access to the Yandex.Market Partner API.
`Client id is invalid`	The specified application ID (the oauth_client_id parameter) is invalid.	Check if the authorization data is correct. If they are correct, get a new app ID, repeat the request with the new authorization data.
`Scope is invalid`	The specified authorization token (the oauth_token parameter) doesn’t have the necessary set of rights.	Get a new authorization token, mention the right to use the Yandex.Market Partner API when you receive it, and repeat the request with the new authorization data.
`Token is invalid`	The specified authorization token (parameter oauth_token) is invalid.	Check if the authorization data is correct. If they are correct, get a new authorization token, repeat the request with the new authorization data.
`User account is disabled`	The user account for which the specified authorization token was issued is blocked.	Contact the Yandex.Market support service.

For the 404 Not Found error:

Description	Explanation	Possible solution
`Feed not found: 'feedId'`	The price list specified in the request isn’t found.	Check if the sent price list ID is correct.
`Login not found: 'login'`	The username specified in the request isn’t found.	Check if the sent username is correct.
`Model not found: 'modelId'`	The model specified in the request isn’t found.	Check if the model ID you are passing is correct.

For the 405 Method Not Allowed error:

Description	Explanation	Possible solution
`Request method 'method' not supported`	The requested HTTP method isn’t supported.	Check the methods supported by the resource. You can find the list of methods in the Requests reference section.

For the 415 Unsupported Media Type error:

Description	Explanation	Possible solution
`Content type 'content-type' not supported`	The requested content type isn’t supported.	Pass one of the supported content types.
`Missing Content-Type`	The content type isn’t specified.	Pass the content type.
`Unknown content-type: 'content-type'`	The requested content type is unknown.	Pass one of the supported content types.

For the 420 Enhance Your Calm error:

Description	Explanation	Possible solution
`Hit rate limit of 'N' parallel requests`	Exceeded the global limit on the number of simultaneous requests to the Yandex.Market Partner API.	Reduce the number of concurrent requests to the partner API within a single store or partner to N requests.
`Hit rate limit of 'N' requests per 'period' for resource 'R'`	The resource restriction for the N number of requests to the R resource over the period for the same store or partner is exceeded.	The time until which the limit applies is specified in the X-RateLimit-Resource-Until header. You can use of the resource after the specified time.

For the 503 Service Unavailable error:

Description	Explanation	Possible solution
`Service temporarily unavailable. Please, try again later`	The server is temporarily unavailable due to high load.	Try repeating the request after a while.

Request example:

GET /v2/campaigns.xml HTTP/1.1
Host: api.partner.market.yandex.ru
Accept: */*
Authorization: OAuth oauth_token=,oauth_client_id=b12320932d4e401ab6e1ba43d553d433

Response example:

<response>
  <errors>
    <error code="UNAUTHORIZED" message="OAuth token is not specified"/>
  </errors>
  <error code="401">
    <message>OAuth token is not specified</message>
  </error>
</response>

Request example:

GET /v2/campaigns.json HTTP/1.1
Host: api.partner.market.yandex.ru
Accept: */*
Authorization: OAuth oauth_token=,oauth_client_id=b12320932d4e401ab6e1ba43d553d433

Response example:

{
  "errors":
  [
    {
      "code": "UNAUTHORIZED",
      "message": "OAuth token is not specified"
    }
  ],
  "error":
  {
    "code": 401,
    "message": "OAuth token is not specified"
  }
}

Источник

Справочник ошибок и ответов API

При выполнении некорректного запроса к системе наше API может вернуть код ошибки, в случае же верного запроса, API вернёт ответ. Вы, конечно, уже обрабатывали ответ сервера в ходе отладки своих виджетов или написании скриптов, взаимодействующих с нашей системой. Для Вашего удобства, мы решили систематизировать все возможные ответы и ошибки, отдаваемые нашей системой и разместить их на отдельной странице. Надеемся это облегчит и ускорит интеграцию Ваших проектов с amoCRM.

Ошибки при валидации данных

Если переданные данные не совпадают с теми, что доступны для сущности, запрос вернет HTTP-код 400 Bad Request и массив с параметрами, которые не подошли под условия.

Пример ошибки валидации данных


{
    "validation-errors": [
        {
            "request_id": "0",
            "errors": [
                {
                    "code": "NotSupportedChoice",
                    "path": "custom_fields_values.0.field_id",
                    "detail": "The value you selected is not a valid choice."
                }
            ]
        }
    ],
    "title": "Bad Request",
    "type": "https://httpstatus.es/400",
    "status": 400,
    "detail": "Request validation failed"
}

Ответы при авторизации

Подробнее об авторизации читайте здесь

Код	HTTP код	Описание
110	401 Unauthorized	Общая ошибка авторизации. Неправильный логин или пароль.
111	401 Unauthorized	Возникает после нескольких неудачных попыток авторизации. В этом случае нужно авторизоваться в аккаунте через браузер, введя код капчи.
112	401 Unauthorized	Возникает, когда пользователь выключен в настройках аккаунта “Пользователи и права” или не состоит в аккаунте.
113	403 Forbidden	Доступ к данному аккаунту запрещён с Вашего IP адреса. Возникает, когда в настройках безопасности аккаунта включена фильтрация доступа к API по “белому списку IP адресов”.
101	401 Unauthorized	Возникает в случае запроса к несуществующему аккаунту (субдомену).

Ответы при работе с контактами

Подробнее о работе с контактами читайте здесь

Код	Описание
202	Добавление контактов: нет прав
203	Добавление контактов: системная ошибка при работе с дополнительными полями
205	Добавление контактов: контакт не создан
212	Обновление контактов: контакт не обновлён
219	Список контактов: ошибка поиска, повторите запрос позднее
330	Добавление/Обновление контактов: количество привязанных сделок слишком большое

Ответы при работе со сделками

Подробнее о работе со сделками читайте здесь

Код	Описание
330	Добавление/Обновление сделок: количество привязанных контактов слишком большое

Ответы при работе с событиями

Подробнее о работе с событиями читайте здесь

Код	Описание
244	Добавление событий: недостаточно прав для добавления события
225	Обновление событий: события не найдены

Ответы при работе с задачами

Подробнее о работе с задачами читайте здесь

Код	Описание
231	Обновление задач: задачи не найдены
233	Добавление событий: по данному ID элемента не найдены некоторые контакты
234	Добавление событий: по данному ID элемента не найдены некоторые сделки
235	Добавление задач: не указан тип элемента
236	Добавление задач: по данному ID элемента не найдены некоторые контакты
237	Добавление задач: по данному ID элемента не найдены некоторые сделки
244	Добавление сделок: нет прав.

Ответы при работе со списками

Подробнее о работе со списками читайте здесь

Код	Описание
244	Добавление/Обновление/Удаление каталогов: нет прав.
281	Каталог не удален: внутренняя ошибка
282	Каталог не найден в аккаунте.

Ответы при работе с элементами каталога

Подробнее о работе с элементами каталога читайте здесь

Код	Описание
203	Добавление/Обновление элементов каталога: системная ошибка при работе с дополнительными полями
204	Добавление/Обновление элементов каталога: дополнительное поле не найдено
244	Добавление/Обновление/Удаление элементов каталога: нет прав.
280	Добавление элементов каталога: элемент создан.
282	Элемент не найден в аккаунте.

Ответы при работе с покупателями

Подробнее о работе с покупателями читайте здесь

Код	Описание
288	Недостаточно прав. Доступ запрещен.
402	Необходимо оплатить функционал
425	Функционал недоступен
426	Функционал выключен

Другие ответы

Ошибки и ответы, не относящиеся к какому-либо конкретному разделу

Код	Описание	Примечание
400	Неверная структура массива передаваемых данных, либо не верные идентификаторы кастомных полей
422	Входящие данные не мог быть обработаны.
405	Запрашиваемый HTTP-метод не поддерживается
402	Подписка закончилась	Вместе с этим ответом отдаётся HTTP код №402 “Payment Required”
403	Аккаунт заблокирован, за неоднократное превышение количества запросов в секунду	Вместе с этим ответом отдаётся HTTP код №403
429	Превышено допустимое количество запросов в секунду	Вместе с этим ответом отдаётся HTTP код №429
2002	По вашему запросу ничего не найдено	Вместе с этим ответом отдаётся HTTP код №204 “No Content”

Источник

Стандартные ответы при ошибках

После успешной обработки запроса Core Reporting API возвращает в теле ответа код статуса HTTP 200 и запрошенные данные.

В случае ошибки API возвращает в ответе соответствующий код статуса HTTP и сведения о ее источнике.
Кроме того, в теле ответа подробно описывается, что привело к ошибке. Пример:

400 invalidParameter

{
 "error": {
  "errors": [
   {
    "domain": "global",
    "reason": "invalidParameter",
    "message": "Invalid value '-1' for max-results. Value must be within the range: [1, 1000]",
    "locationType": "parameter",
    "location": "max-results"
   }
  ],
  "code": 400,
  "message": "Invalid value '-1' for max-results. Value must be within the range: [1, 1000]"
 }
}

Примечание. Текст описания может изменяться и не должен использоваться при обработке в приложении.

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

Код	Причина	Описание	Рекомендуемые действия
400	invalidParameter	Параметр запроса имеет неверное значение. В полях `locationType` и `location` ответа приводятся сведения о недопустимом значении.	Прежде чем повторить попытку, устраните проблему. Указанный в ответе параметр должен получать допустимое значение.
400	badRequest	Неверный запрос. Например, отсутствует идентификатор родительского элемента, или запрошена недопустимая комбинация параметров и показателей.	Прежде чем повторить попытку, устраните проблему. Внесите необходимые изменения в запрос к API.
401	invalidCredentials	Неверный или устаревший токен аутентификации.	Прежде чем повторить попытку, устраните проблему. Получите новый токен аутентификации.
403	insufficientPermissions	У пользователя нет разрешений на работу с объектом, указанным в запросе.	Прежде чем повторить попытку, устраните проблему. Получите необходимые разрешения для работы с указанным объектом.
403	dailyLimitExceeded	Пользователь превысил дневную квоту для проекта или профиля.	Прежде чем повторить попытку, устраните проблему. Вы исчерпали свою дневную квоту. Подробнее об ограничениях и квотах в API…
403	usageLimits.userRateLimitExceededUnreg	Приложение нужно зарегистрировать в Google API Console.	Прежде чем повторить попытку, устраните проблему. Чтобы получить полную квоту, зарегистрируйтесь в Google API Console.
403	userRateLimitExceeded	Пользователь превысил ограничение на количество запросов. По умолчанию с одного IP-адреса можно выполнять один запрос в секунду. Это ограничение можно увеличить в Google API Console, но число запросов в секунду в любом случае не должно превышать 10.	Попробуйте применить алгоритм экспоненциальной выдержки. Уменьшите скорость отправки запросов.
403	rateLimitExceeded	Превышено глобальное или общее ограничение частоты отправки запросов.	Попробуйте применить алгоритм экспоненциальной выдержки. Уменьшите скорость отправки запросов.
403	quotaExceeded	Достигнуто ограничение в 10 параллельных запросов на один профиль для Core Reporting API.	Попробуйте применить алгоритм экспоненциальной выдержки. Подождите, пока будет завершен хотя бы один выполняемый запрос.
429	RESOURCE_EXHAUSTED AnalyticsDefaultGroupCLIENT_PROJECT-1d	Достигнута дневная квота запросов для проекта.	Прежде чем повторить попытку, устраните проблему. Вы исчерпали свою дневную квоту. Подробнее об ограничениях и квотах в API…
429	RESOURCE_EXHAUSTED AnalyticsDefaultGroupCLIENT_PROJECT-100s	Достигнута квота для проекта на количество запросов, отправляемых за 100 секунд.	Попробуйте применить алгоритм экспоненциальной выдержки. Уменьшите скорость отправки запросов.
429	RESOURCE_EXHAUSTED AnalyticsDefaultGroupUSER-100s	Достигнута квота для проекта на количество запросов, отправляемых за 100 секунд.	Попробуйте применить алгоритм экспоненциальной выдержки. Уменьшите скорость отправки запросов.
429	RESOURCE_EXHAUSTED DiscoveryGroupCLIENT_PROJECT-100s	Достигнута квота на количество запросов обнаружения, отправляемых за 100 секунд.	Ответы на запросы обнаружения меняются редко. Сохраняйте их в кеше компьютера или применяйте алгоритм экспоненциальной выдержки. Уменьшите скорость отправки запросов.
500	internalServerError	Непредвиденная ошибка сервера.	Не выполняйте этот запрос повторно.
503	backendError	Ошибка сервера.	Не выполняйте этот запрос повторно.

Обработка ответов на ошибки 500 и 503

Ошибки 500 и 503 могут возникнуть при высокой нагрузке или сложных запросах. Попробуйте указать менее продолжительный отрезок времени. Кроме того, можно использовать алгоритм экспоненциальной выдержки. Частота возникновения таких ошибок зависит от представления (профиля) и объема связанных с ним отчетных данных. В одном представлении (профиле) запрос может заканчиваться ошибкой 500 или 503, а в другом выполняться корректно.

Реализация алгоритма экспоненциальной выдержки

В рамках алгоритма экспоненциальной выдержки клиент постепенно увеличивает интервалы между попытками выполнить ошибочный запрос. Это стандартная стратегия обработки ошибок в сетевых приложения является обязательной для клиентов Core Reporting API. Кроме того, она позволяет более эффективно использовать пропускную способность, сократить количество запросов, необходимое для получения успешного ответа, а также увеличить количество параллельно выполняемых в среде запросов.

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

Выполняется запрос к API.
Возвращается ответ с кодом ошибки и информацией для повторного выполнения.
Реализуется задержка величиной 1 + random_number_milliseconds с.
Запрос повторяется.
Возвращается ответ с кодом ошибки и информацией для повторного выполнения.
Реализуется задержка величиной 2 + random_number_milliseconds с.
Запрос повторяется.
Возвращается ответ с кодом ошибки и информацией для повторного выполнения.
Реализуется задержка величиной 4 + random_number_milliseconds с.
Запрос повторяется.
Возвращается ответ с кодом ошибки и информацией для повторного выполнения.
Реализуется задержка величиной 8 + random_number_milliseconds с.
Запрос повторяется.
Возвращается ответ с кодом ошибки и информацией для повторного выполнения.
Реализуется задержка величиной 16 + random_number_milliseconds с.
Запрос повторяется.
Если запрос по-прежнему не удается выполнить, повторные попытки прекращаются, и регистрируется ошибка.

Атрибут random_number_milliseconds определяет случайную задержку величиной не более 1000 мс и позволяет предотвратить ошибки блокировки в некоторых параллельных реализациях.
Значение атрибута random_number_milliseconds переопределяется после каждого периода ожидания.

Примечание. Величина задержки всегда определяется по формуле (2^n) + random_number_milliseconds, где n – это целое число, которое изначально равно 0 и монотонно увеличивается на 1 после каждой итерации, то есть после каждого запроса.

По умолчанию выполнение алгоритма прекращается при n=5, которое соответствует общей задержке около 32 с. Это ограничение позволяет предотвратить бесконечные попытки выполнить запрос и свидетельствует о наличии неустранимой ошибки.

Ниже показана реализация этого алгоритма на языке Python для обработки ошибок в методе makeRequest.

import random
import time
from apiclient.errors import HttpError

def makeRequestWithExponentialBackoff(analytics):
  """Wrapper to request Google Analytics data with exponential backoff.

  The makeRequest method accepts the analytics service object, makes API
  requests and returns the response. If any error occurs, the makeRequest
  method is retried using exponential backoff.

  Args:
    analytics: The analytics service object

  Returns:
    The API response from the makeRequest method.
  """
  for n in range(0, 5):
    try:
      return makeRequest(analytics)

    except HttpError, error:
      if error.resp.reason in ['userRateLimitExceeded', 'quotaExceeded',
                               'internalServerError', 'backendError']:
        time.sleep((2 ** n) + random.random())
      else:
        break

  print "There has been an error, the request never succeeded."

Источник

Коды состояний в REST

200 * (OK)

201 * (Created — Создано)

202 (Accepted — Принято)

203 (Non-Authoritative Information — Неавторитетная информация)

204 * (No Content — Нет контента)

205 — (Reset Content — Сброшенное содержимое)

206 — (Partial Content — Частичное содержимое)

300 — (Multiple Choices — Несколько вариантов)

301 (Moved Permanently — Перемещено навсегда)

302 (Found — Найдено)

303 (See Other — Смотрите другое)

304 * (Not Modified — Не изменен)

305 — (Use Proxy — Используйте прокси)

307 (Temporary Redirect — Временный редирект)

308 — (Permanent Redirect — Постоянное перенаправление) (experimental)

400 * (Bad Request — Плохой запрос)

401 * (Unauthorized — Неавторизован)

402 — (Payment Required — Требуется оплата)

403 * (Forbidden — Запрещено)

404 * (Not Found — Не найдено)

405 (Method Not Allowed — Метод не разрешен)

406 (Not Acceptable — Неприемлемый)

407 — (Proxy Authentication Required — Требуется прокси-аутентификация)

408 — (Request Timeout — Таймаут запроса)

409 * (Conflict — Конфликт)

410 — (Gone — Исчез)

411 — (Length Required — Требуется длина)

412 — (Precondition Failed — Предварительное условие не выполнено)

413 — (Request Entity Too Large — Сущность запроса слишком большая)

414 — (Request-URI Too Long — Запрос-URI Слишком длинный)

415 (Unsupported Media Type — Неподдерживаемый медиа тип)

428 — (Precondition Required — Требуется предварительное условие)

429 — (Too Many Requests — Слишком много запросов)

431 — (Request Header Fields Too Large — Слишком большие поля заголовка запроса)

444 — (No Response — Нет ответа) (Nginx)

451 — (Unavailable For Legal Reasons — Недоступен по юридическим причинам)

500 * (Internal Server Error — Внутренняя ошибка сервера)

501 (Not Implemented — Не реализован)

502 — (Bad Gateway — Плохой шлюз)

503 — (Service Unavailable — Служба недоступна)

504 — (Gateway Timeout — Таймаут шлюза)

505 — (HTTP Version Not Supported — Версия HTTP не поддерживается)

510 — (Not Extended — Не расширен)

Причины появления ошибки сервера 401 и способы ее устранения на стороне пользователя

Устранение ошибки 401 администратором веб-ресурса

Дополнительная информация об ошибке с кодом 401

Справочник ошибок и ответов API

Ошибки при валидации данных

Пример ошибки валидации данных

Ответы при авторизации

Ответы при работе с контактами

Ответы при работе со сделками

Ответы при работе с событиями

Ответы при работе с задачами

Ответы при работе со списками

Ответы при работе с элементами каталога

Ответы при работе с покупателями

Другие ответы

Стандартные ответы при ошибках

Обработка ответов на ошибки 500 и 503

Реализация алгоритма экспоненциальной выдержки

Не пропустите эти материалы по теме: