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
Источник

Это список ошибок, которые может выдать API. Настоятельно рекомендуем разработчикам логгировать и анализировать все ошибки API, и вовремя реагировать на них. Например, устранять поломки и распространять обновления среди ваших пользователей. Мы активно защищаем API от пустых запросов, которые, например, генерируют одни и те же ошибки если запрос был повторен. Это включает бан IP, подсетей, а также замораживание учетных записей в некоторых серьезных случаях.

Идентификатор Код Описание
0 Код 0 для «нет ошибок».
1 ERROR_KEY_DOES_NOT_EXIST Авторизационный ключ не был найден в системе. Убедитесь что ключ скопирован правильно, без пробелов и знаков табуляции.
2 ERROR_NO_SLOT_AVAILABLE Нет свободных работников в данный момент, клиент должен либо повысить ставку в настройках API, либо выбрать менее загруженное время для создания задач. Больше информации о том как работают прокси можно найти в FAQ.
3 ERROR_ZERO_CAPTCHA_FILESIZE Размер загружаемой капчи меньше 100 байт.
4 ERROR_TOO_BIG_CAPTCHA_FILESIZE Размер загружаемой капчи больше 500,000 байт.
10 ERROR_ZERO_BALANCE Баланс учетной записи равен нулю или отрицательный.
11 ERROR_IP_NOT_ALLOWED Запрос с данным ключом доступа не разрешен с вашего IP адреса. Пожалуйста проверьте свои настройки безопасности в личном кабинете.
12 ERROR_CAPTCHA_UNSOLVABLE 5 работников не смогли решить капчу. Клиенты платят за такие задачи так как они потребляют время работников.
12 ERROR_BAD_DUPLICATES Функция 100% распознавания не сработала, так как закончились попытки распознавания.
14 ERROR_NO_SUCH_METHOD Запров в API был сделан по несуществующему имени метода. Обычно это случается, когда программисты неправильно копируют его название.
15 ERROR_IMAGE_TYPE_NOT_SUPPORTED Не смогли определить тип картики по EXIF заголовку или такой формат не поддерживается. Поддерживаются только JPG, GIF, PNG. Картинки должны содержать EXIF заголовок.
16 ERROR_NO_SUCH_CAPCHA_ID Запрашиваемая вами капча не была найдена в ваших активных капчах или устарела.
Капчи удаляются из API через 60 секунд после завершения ее решения работником. В течение этого периода нужно присылать все запросы на получение результата капчи, а также отчеты о правильном/неправильном результате.
21 ERROR_IP_BLOCKED Ваш IP был заблокирован из-за некорректного использования API. Узнайте причину здесь.
22 ERROR_TASK_ABSENT Свойство «task» пустое или не указано в методе createTask.
23 ERROR_TASK_NOT_SUPPORTED Тип задачи не поддерживается или набран некорректно. Пожалуйста проверьте свойство «type» в объекте задачи.
24 ERROR_INCORRECT_SESSION_DATA Некоторые требуемые значения для успешной эмуляции пользователя отсутствуют. Вывод API содержит информацию о том, чего не хватает.
25 ERROR_PROXY_CONNECT_REFUSED Не смогли подсоединиться к прокси задачи, таймаут соединения.
26 ERROR_PROXY_CONNECT_TIMEOUT Не смогли подсоединиться к прокси задачи, таймаут чтения.
27 ERROR_PROXY_READ_TIMEOUT Таймаут чтения прокси
28 ERROR_PROXY_BANNED IP прокси забанен в целевом сервисе.
29 ERROR_PROXY_TRANSPARENT Задача отклонена на стадии проверки прокси. Он должен быть непрозрачным и прятать IP наших серверов. Используйте наш прокси чекер чтобы отладить ваши прокси.
30 ERROR_RECAPTCHA_TIMEOUT Таймаут решения рекапчи, скорее всего из-за медленного прокси сервера или сервера Google.
31 ERROR_RECAPTCHA_INVALID_SITEKEY Провайдер капчи сообщил о неверном ключе капчи.
32 ERROR_RECAPTCHA_INVALID_DOMAIN Провайдер капчи сообщил, что домен не зарегистрирован на этом ключе капчи.
33 ERROR_RECAPTCHA_OLD_BROWSER Провайдер капчи сообщил, что user-agent браузера не совместим с их скриптами.
34 ERROR_TOKEN_EXPIRED Провайдер капчи сообщил о том, что истек срок действия дополнительного токена. Пожалуйста попробуйте снова с новым токеном.
35 ERROR_PROXY_HAS_NO_IMAGE_SUPPORT Прокси не поддерживает передачу картинок от серверов Google. Используйте наш прокси чекер чтобы отладить ваши прокси.
36 ERROR_PROXY_INCOMPATIBLE_HTTP_VERSION Прокси не поддерживает длинные GET запросы больше 2000 байт и не поддерживает SSL подключения. Используйте наш прокси чекер чтобы отладить ваши прокси.
49 ERROR_PROXY_NOT_AUTHORISED Логин и пароль прокси неправильные. Используйте наш прокси чекер чтобы отладить ваши прокси.
51 ERROR_INVALID_KEY_TYPE Передан sitekey от другого типа рекапчи. Попробуйте решить ее как V2, V2-invisible или V3.
52 ERROR_FAILED_LOADING_WIDGET Не смогли отобразить виджет капчи в браузере работника. Пожалуйста попробуйте прислать новую задачу.
53 ERROR_VISIBLE_RECAPTCHA Попытка решить обычную рекапчу как невидимую. Уберите флаг ‘isInvisible’ из запроса к API.
54 ERROR_ALL_WORKERS_FILTERED

Не осталось работников, которые не были бы отфильтрованы методом reportIncorrectRecaptcha.
55 ERROR_ACCOUNT_SUSPENDED Система заблокировала ключ по серьезной причине. Свяжитесь с поддержкой чтобы узнать причину.
56 ERROR_TEMPLATE_NOT_FOUND Шаблон AntiGate не был найден во время создания задачи.
57 ERROR_TASK_CANCELED Задача AntiGate была отменена работником. В поле «errorDescription» указана причина отмены.
Источник

When building APIs for the first time, it is important to understand error status codes and how they impact the overall performance of the API. Error status codes are essential for ensuring that the API is functioning correctly, communicating errors and warnings to the user or system, and providing a seamless experience.

It is important to understand the different types of error status codes, what they mean, and how to interpret them so that your API will function properly.

This blog post will explore the various API error status codes and how to interpret them when building APIs for the first time.

It will provide a comprehensive discussion on the different types of error codes and the best practices for handling them, as well as provide a few tips to help make your API building experience as smooth as possible.

  • What are API error Codes?
  • Client-side status code

    1. 404 — Not Found
    2. 401 — Unauthorized
    3. 403 — Forbidden
    4. 400 — Bad Request
    5. 429 — Too Many Requests
  • Server-side status code

    1. 500 — Internal Server Error
    2. 502 — Bad Gateway
    3. 503 — Service Unavailable
    4. 504 — Gateway Timeout
    5. 501 — Not Implemented
  • Best practices for handling API Error codes

What are API error Codes?

API error codes are standardized status codes that are returned by an API (Application Programming Interface) in response to a client’s request. These codes are used to indicate whether the requested operation was successful or not, and if not, to provide information on the type of error that occurred.

API error codes are typically three-digit numbers, with the first digit indicating the general category of the error, and the remaining two digits specifying the particular error within that category. For example, a 404 error code is a common error that indicates the requested resource was not found on the server.

API Error Status CodesAPI Error Codes

API Error Codes

By providing standardized error codes, APIs can communicate more effectively with clients and developers, and allow them to quickly diagnose and address any issues that arise during the use of the API.

For example, Suppose a client sends a request to an API to retrieve information about a specific resource, such as a user profile, but the API is unable to find that resource. In this case, the API may return a 404 error code, with a message indicating that the requested resource was not found.

The 404 error code is a standardized HTTP status code, which indicates that the server was unable to find the requested resource. The first digit «4» indicates that the error falls under the category of client errors, meaning that the error was caused by an issue with the client’s request, rather than an issue with the server. The remaining two digits «04» specify the specific error within that category, in this case, «not found».

The client can then use this information to understand that the requested resource was not found, and take appropriate action, such as displaying an error message to the user or retrying the request with different parameters.

There are two types of error status codes when you build an API for the first time.

  1. Client-side Status Code
  2. Server-side Status Code

Client-side Status Code

Client-side status codes are HTTP response codes that are generated by a client’s web browser in response to a server’s attempt to fulfill the client’s request. These codes are used to communicate information about the status of the request to the client, and they can help the client to take appropriate action based on the response.

The 4XX series of status codes often refers to client-side failures, though they can also result from modifications to the API. The top 5 client-side status error codes are listed below, along with explanations of how to fix them.

There are 5 common client-side status codes when you build an API:

1. 400 — Bad Request

The 400 Bad Request error is an HTTP response status code that indicates that the server cannot understand the request sent by the client because it was malformed or incomplete. This means that the server is unable to process the request and return the desired response.

Ways to fix the 400 — Bad Request error

  1. Check the URL: Make sure the URL you’re trying to access is correct and complete.
  2. Clear your cache and cookies: Clearing your browser’s cache and cookies can sometimes help fix the 400 error.
  3. Check your request syntax: Double-check that your request syntax is correct, including all necessary headers and parameters.
  4. Check for outdated software: Make sure that your web browser, operating system, and other software are up-to-date.
  5. Disable browser extensions: Try disabling any browser extensions that may be interfering with your web requests.
  6. Contact the website owner: If you’re trying to access a specific website, you can try contacting the website owner or technical support team for assistance.
  7. Try a different browser or device: If you’re still having trouble after trying the above steps, you can try accessing the website from a different browser or device.

The client request has not been fulfilled because it does not contain proper authentication credentials for the requested resource, as indicated by the HyperText Transfer Protocol (HTTP) 401 Unauthorized response status code.

Because the client request does not contain proper authentication credentials for the requested resource, the HyperText Transfer Protocol (HTTP) 401 Unauthorized response status code indicates that the client request has not been fulfilled.

This error indicates that the website or web application was unable to authenticate the request that was made. Fortunately, this problem may typically be quickly fixed.

Ways to fix 401 — Unauthorized Error

  • Verify that you are using a valid user ID and password to log in.
  • It may be worthwhile to momentarily disable password security for the troublesome area of your website if you’re a webmaster trying to fix the 401 issue.
  • It may be worthwhile to momentarily disable password security for the troublesome area of your website if you’re a webmaster trying to fix the 401 issue. Clear it!

3. 403 — Forbidden

Although the server recognizes the request, it will not grant access, as shown by the HTTP response status code 403 Forbidden. For the 403 Forbidden status code, re-authenticating has no effect, even though this status is comparable to 401. Such as insufficient privileges to a resource, the access is connected to the application logic.

Simply put, it indicates that the website’s content you’re seeking to access is being banned for a specified reason. Although the cause could be something in your power, the content owner or server is more likely to be to blame.

A request that the server cannot accept results in a 403 Forbidden error. This frequently happens because of firewall rules that categorically forbid making this particular request, but other settings, including permissions, may also restrict access based on user privileges.

Ways to fix 403 — Forbidden error

  • If you’ve made it this far and none of the previous fixes have worked, there’s a good possibility that the issue is the result of a malfunctioning or incompatible plugin. Try disabling plugins.
  • Verify the name of the homepage on your website; it should be index.html or index.php. The first and easiest is to change the homepage’s name to index.html or index.php.

4. 404 — Not Found

A website user will be informed if a requested page is unavailable with the status code 404. The Hypertext Transfer Protocol response codes on the web include 404 and various response status codes. The 404 error number indicates that a client’s requested webpage was not found by the server.

These happen when a page cannot be located. If the URL is typed incorrectly or the page has been erased, this may occur. These 400 errors show that the request cannot be processed by the server. This may occur if there is a coding issue or if the website is unavailable for maintenance.

Ways to fix 404 — Page Not Found Error

  • Open a new window and try to close the current one.
  • erase the cache. Delete the history and data from your browser.
  • To be sure you typed in the proper website address in the search bar, double-check the URL.
  • Make sure your website doesn’t include any broken links.

5. 429 — Too Many Requests

When a user sends too many requests in a short period, the HTTP 429 Too Many Requests response status code shows this («rate limiting»). This answer may have a Retry-After header stating how long it should be before a fresh request is made.

The lack of resources to handle so many concurrent requests is the main reason behind 429 errors. If this error, for instance, appears on a hosting server, it may indicate that the package you are using has a cap on the number of requests you are permitted to submit.

Ways to fix 429 — Too many requests error

  • The next time you come, the browser can load the website more quickly thanks to cached data. But, as this data builds up, the 429 error may appear. Thus, the first step is to empty the cache on your browser.
  • Conflicts may also result from WordPress themes with poor coding. Switching to a default WordPress theme is the simplest method to address this problem.

Server-side Status Code

Server-side status codes are HTTP response codes that are generated by a web server in response to a client’s request for a resource. These status codes provide information about the status of the server’s attempt to fulfill the request, and they help to ensure that the client and server can communicate effectively.

The 5XX group of status codes typically returns in response to a server error, but if the server misses an invalid API call that ought to produce a 4XX answer, it may also return a 5XX error.

1. 500 — Internal Server Error

The HyperText Transfer Protocol (HTTP) 500 Internal Server Error server error response code denotes that the request could not be processed by the server due to an unexpected condition. This error message is an all-purpose «catch-all» message.

Since the 500 Internal Server Error is a server-side issue, it is most likely not your computer or internet connection that is at fault, but rather the server hosting the website. Although unlikely, there could be a problem on your end, in which case you can try the following: Refresh the website.

When a server-side issue prohibits Apache from handling a request and providing a suitable response, Apache returns a 500 Internal Server Error. This may be the result of several factors, including flawed code, insufficient file permissions, and missing files mentioned in the code.

Ways to fix 500 — Internal Server Error:

  • Attempt refreshing the page. The website may return immediately if the host or server is just overloaded.
  • Themes and plugins from unofficial sources might easily result in 500 internal server issues. Deactivate them.

2. 501 — Not Implemented

The server does not support the functionality required to complete the request if the HyperText Transfer Protocol (HTTP) 501 Not Implemented server error response code is returned. The Retry-After header, which notifies the requester when to check back to see if the functionality is supported by then, may also be sent by this status.

You can’t fix the problem yourself because it’s a server-side error; it needs to be fixed by the server and website management.

An HTTP error message, also known as an HTTP status code, is returned by a browser when it accesses a page and discovers something that doesn’t operate properly. A problem on the server is indicated if the message’s code begins with a 5.

This indicates that anything on the server’s end of the website is malfunctioning and preventing a full page load. The root causes of this problem, however, can vary.

Ways to fix 501 — Not Implemented Error:

  • Malware or viruses on the computer could be the cause of Error 501. Thus, it’s crucial to do a comprehensive scan of your antivirus software and maintain it updated.
  • Checking the server’s log files to see if any error messages can aid with the problem can be another idea for resolving it.

3. 502 — Bad Gateway

A 502 bad gateway message denotes that a server received a faulty answer from another server. In essence, you have established a connection with some sort of temporary device (such as an edge server) that should fetch all the information required to load the page.

The notice identifies the issue as anything with that process that went wrong. It denotes a server issue rather than one with your device, router, or internet connection. There’s a good chance that other website visitors are having the same issue.

Ways to fix 502 — Bad Gateway Error

  • Deciding to re-route your internet traffic over a virtual private network (VPN) can assist you to figure out whether the connection to the site is having problems because of your ISP or something else.
  • Clearing the browser’s cache might help if refreshing the browser a few times doesn’t work.
  • Check the web server logs from the time the error occurred.

4. 503 — Service Unavailable

An HTTP response status code of 503 Service Unavailable indicates that although your web server is operational, it is now unable to handle a request. It’s challenging to determine the precise cause of the problem because the error message is only a general one.

You are not at fault because a 503 error on the HTTP protocol usually signifies that the server is having problems. But, you may troubleshoot and resolve the issue by following a few straightforward actions. When you get a 503 service unavailable error message, you could be left scratching your head and wondering what went wrong.

Ways to 503 — Service Unavailable Error:

  • A server employs Memory, CPU, I/O, entry processes, and website inodes as resources. You can determine whether the problem is connected to resource limitations by looking at these metrics.
  • Several web hosting typically gives their users automatic upgrades. You have the opportunity to change the server configuration settings and turn off automatic updates.

5. 504 — Gateway Timeout

The 504 «Gateway Timeout» Error denotes that the browser attempted to send an HTTP request to the server but was unable to do so because it did not receive a timely response from another server. You may usually fix it by refreshing the website.

A 504 Gateway Timeout Error denotes that your web server did not immediately receive a response from an upstream server when it attempted to load one of your web pages. Simply said, the communication between your web servers isn’t happening swiftly enough.

Ways to fix 504 — Gateway Timeout Error:

  • Try opening the WordPress website in incognito mode and using a different browser.
  • An alternative computer, network connection, or mobile device might be able to load the page. To determine whether the issue is with the hardware or the internet connection, you may also try restarting the network devices.

Discover the secrets of HTTP status codes with our Complete Guide! Learn how to use them effectively to communicate with clients and servers, and how to handle errors gracefully.

Best practices for handling API Error Codes

  1. Use standardized error codes: Use well-defined error status codes consistent with industry standards and HTTP specifications. This can make it easier for clients to understand and handle errors.
  2. Provide informative error messages: Include informative and precise error messages and error codes to help clients understand the reason for the error and what action they can take to resolve it.
  3. Be consistent: Ensure consistency in the format and content of error messages and error status codes across all API endpoints to avoid confusion and simplify client error handling.
  4. Use appropriate HTTP methods: Use appropriate HTTP methods to indicate the nature of the request and the desired action. For example, use GET for retrieving data and POST for creating new resources.
  5. Implement retries: Allow clients to retry failed requests after a specified interval to reduce the impact of temporary network or server issues.
  6. Log errors: Log all API errors, including error codes, error messages, and any relevant details, to help diagnose and troubleshoot issues.
  7. Use versioning: Use versioning to indicate API changes and allow clients to migrate to new versions at their own pace without disrupting existing applications.

Here’s an example of how to handle API errors in a Node.js application using the Express framework:

const express = require('express');
const app = express();

app.get('/users/:id', (req, res) => {
  const userId = req.params.id;
  if (!isValidUserId(userId)) {
    const error = new Error('Invalid user ID');
    error.status = 400; // Set the HTTP status code
    return next(error);
  }
  // Continue with the normal request handling
  // ...
});

// Error handler middleware
app.use((err, req, res, next) => {
  const statusCode = err.status || 500; // Default to 500 if status code not set
  res.status(statusCode).json({
    message: err.message
  });
});

// Helper function to validate user IDs
function isValidUserId(id) {
  // Check if ID is a non-empty string of digits
  return /^\d+$/.test(id);
}

In this example, the API endpoint /users/:id accepts a request to retrieve a user’s information based on their ID. The isValidUserId function is used to validate the user ID, and if it is found to be invalid, an error is thrown with a message of «Invalid user ID» and a status code of 400. The error is then passed to the error handler middleware using the next function, which sets the appropriate status code and sends a JSON response with the error message.

The error handler middleware is a catch-all middleware that handles any errors that occur in the application. It extracts the status code and error message from the error object and sends a JSON response to the client with that information.

By following this pattern, you can ensure that any errors that occur during the handling of an API request are properly handled and communicated to the client in a consistent and informative manner.

Conclusion

Any issue that prevents access to the website should be resolved as quickly as possible. This is because while your page is down, your visitors are unable to access your material, which is bad for your business. After all, you could lose both the visit and a potential client.

The detrimental effects of unavailability on the SEO strategy are one of the key issues they create. This is due to Google periodically crawling the website’s pages for indexing. Hence, it will produce an error message if it tries to access the website and discovers that it is not available.

Refreshing the page and clearing the cache are two simple things that provide reliable solutions for any type of error. Hence, take into account the potential reasons for the problem and the suggested fixes to your website.

Atatus API Monitoring and Observability

Atatus provides Powerful API Observability to help you debug and prevent API issues. It monitors the consumer experience and is notified when abnormalities or issues arise. You can deeply understand who is using your APIs, how they are used, and the payloads they are sending.

Atatus’s user-centric API observability tracks how your actual customers experience your APIs and applications. Customers may easily get metrics on their quota usage, SLAs, and more.

It monitors the functionality, availability, and performance data of your internal, external, and third-party APIs to see how your actual users interact with the API in your application. It also validates rest APIs and keeps track of metrics like latency, response time, and other performance indicators to ensure your application runs smoothly.

Try your 14-day free trial of Atatus!

Источник

Содержание:

  • Общие сведения
  • Формат ошибок
    • Формат ответа методов API в случае ошибок
      • Структура ответа
      • Описание параметров
  • Описание общих ошибок API

Общие сведения

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

Формат ошибок

Формат ответа методов API в случае ошибок

Структура ответа

  • JSON
  • XML 
{  
   "metadata":{  
      "status":400,
      "detail":"abc",
      "generated_at":"2015-06-18 12:37:28"
   },
   "errors":[  
      {  
         "code":281016,
         "title":"ошибка упрощённой отправки",
         "detail":"контрагент с минимальным набором данных не может быть отправителем по заказу",
         "link":"https://dev.dellin.ru/api/ordering/request/#error_281016",
         "fields":["receiver"]
      },
      {  
         "code":281017,
         "title":"Недопустимое значение параметра",
         "detail":"Данный параметр может содержать только значения из списка доступных значений",
         "link":"https://dev.dellin.ru/api/ordering/request/#error_281017",
         "fields":["requester"],
         "validValues":[1, 2, 3]
      },
      {  
         "code":117004,
         "title":"значение не найдено в справочнике",
         "detail":"необходимо выбрать значение из соответствующего справочника",
         "link":"https://dev.dellin.ru/calculation/pickup/#error_117004",
         "fields":["requester"],
         "badValues":["0xa77fcf6a449164ed490133777a68bd00"]
      }
   ]
}
<response>
   <metadata>
      <status>400</status>
      <detail>abc</detail>
      <generated_at>2015-06-18 12:37:28</generated_at>
   </metadata>
   <errors>
      <code>281016</code>
      <title>ошибка упрощённой отправки</title>
      <detail>контрагент с минимальным набором данных не может быть отправителем по заказу</detail>
      <link>https://dev.dellin.ru/api/ordering/request/#error_281016</link>
      <fields>receiver</fields>
   </errors>
   <errors>
      <code>281017</code>
      <title>Недопустимое значение параметра</title>
      <detail>Данный параметр может содержать только значения из списка доступных значений</detail>
      <link>https://dev.dellin.ru/api/ordering/request/#error_281017</link>
      <fields>requester</fields>
      <validValues>1</validValues>
      <validValues>2</validValues>
      <validValues>3</validValues>
   </errors>
   <errors>
      <code>117004</code>
      <title>значение не найдено в справочнике</title>
      <detail>необходимо выбрать значение из соответствующего справочника</detail>
      <link>https://dev.dellin.ru/calculation/pickup/#error_117004</link>
      <fields>requester</fields>
      <badValues>0xa77fcf6a449164ed490133777a68bd00</badValues>
   </errors>
</response>

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

Response
Параметр Тип Описание
metadata object Информация об оформленной заявке
metadata.status integer

Эмуляция http-кода состояния
metadata.detail string Текстовое описание ответа сервера
metadata.generated_at string Дата и время генерации ответа сервера
errors array of Response.Errors Перечень ошибок
Response.Errors
Параметр Тип Описание
code integer Номер ошибки
title string

Краткое описание ошибки
detail string Детальное описание ошибки
link string Ссылка на документацию
fields array of string Список параметров в запросе к методу, вызвавших ошибку
validValues array of string Список доступных значений параметра
badValues array of string Список ошибочных значений, переданных в параметре

Описание общих ошибок API

Номер ошибки http-код Краткое описание ошибки Детальное описание ошибки

100001

 415 Некорректный content-type Допустимые значения content-type: application/json (стандарт RFC4627) и text/xml (стандарт RFC3023)

100002

 404 Метод не найден Проверьте правильность адреса метода

100003

 410 Метод отключен Запрошенный метод более не доступен

100004

 403 Отсутствует доступ к методу Доступ к методу предоставляется по требованию. Для получения доступа обратитесь к персональному менеджеру или в техническую поддержку

100005

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

100006

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

101001

 401 Требуется авторизация Не передан API-ключ

101002

 401 Требуется авторизация Передан недействительный API-ключ

101003

 401 Требуется авторизация Требуется передать параметр sessionID

101004

 401 Требуется авторизация Время жизни сессии истекло

101005

 401 Требуется авторизация Сессия не найдена или создана с другим API-ключом

101006

 401 Требуется авторизация Неверный логин или пароль

101007

 401 Требуется авторизация API-ключ заблокирован. Обратитесь в техническую поддержку

101008

 401 Ошибка парсинга Запрос не соответствует формату json

101009

 401 Ошибка парсинга Запрос не соответствует формату xml

110001

 400 Неверный формат параметра Значение, переданное в параметре, не соответствует требуемому формату

110002

 400 Ошибка типизации Значение, переданное в параметре, имеет некорректный тип

110003

 400 Отсутствует обязательный параметр Отсутствует обязательный параметр

110004

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

110005

 400 Допустима передача только одного из параметров Указаны взаимоисключающие параметры, только один из которых может присутствовать в запросе

110006

 400 Превышено ограничение на длину списка Количество элементов в списке превышает максимально допустимое

110007

 400 Объект не существует Не найден объект с указанным ID. Проверьте правильность переданного значения

110008

 400 Недопустимый набор параметров Указанные параметры не должны участвовать в запросе

110010

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

120001

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

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

(Причина: Сервис calculateCustomers не отвечает)

120002

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

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

(Причина: Сервис calculateCustomers вернул неизвестную ошибку)

120101

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

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

(Причина: Сервис calculateCustomersV2 не отвечает)

120102

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

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

(Причина: Сервис calculateCustomersV2 вернул неизвестную ошибку)

120201

 400 Ошибка в параметрах запроса

Переданы неправильные параметры в запрос

(Причина: Переданы некорректные данные в getOrdersTracker)

120301

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

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

(Причина: Сервис getPaymentsByOrders не отвечает)

121001

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

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

121002

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

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

130001

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

130002

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

130003

 400 Указан некорректный документ, удостоверяющий личность Проверьте правильность переданных значений

130004

 400 Не передан ни один из обязательных параметров

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

130005

 400 Отсутствует обязательный параметр Отсутствует обязательный параметр

130006

 400 Значение превышает допустимое Габариты превышают допустимые размеры

130007

 400 Неверный формат параметра Значение, переданное в параметре, не соответствует требуемому формату

130008

400

 Недопустимое значение параметра Детальное описание ошибки содержит уточняющую информацию. Текст варьируется в зависимости от проверяемого параметра

130009

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

130010

 400 Отсутствует согласие с тарифами и правилами перевозки Детальное описание ошибки содержит уточняющую информацию. Текст варьируется в зависимости от проверяемого параметра

130014

 400 Ошибка наложенного платежа Детальное описание ошибки содержит уточняющую информацию. Текст варьируется в зависимости от проверяемого параметра

130015

 400 Ошибка оформления услуги Детальное описание ошибки содержит уточняющую информацию. Текст варьируется в зависимости от проверяемого параметра

130017

 400 Невозможно оформить заявку на указанное время —

130021

 400 Услуга недоступна Детальное описание ошибки содержит уточняющую информацию. Текст варьируется в зависимости от проверяемого параметра

130022

 400 Указан некорректный адрес Детальное описание ошибки содержит уточняющую информацию. Текст варьируется в зависимости от проверяемого параметра

130023

 400 Выбран недопустимый терминал Выбран недопустимый терминал

130024

 400 Превышено ограничение на длину списка Превышено максимальное количество контрагентов в адресной книге (10000). Необходимо удалить часть записей или обратиться в службу поддержки

150001

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

150002

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

180001

 400 Указан некорректный документ, удостоверяющий личность Проверьте правильность переданных значений

180002

 400 Указан некорректный адрес Указан некорректный адрес

180003

 400 Выбран недопустимый терминал Выбранный терминал не может принять груз с указанными ВГХ

180004

 400 Услуга недоступна Детальное описание ошибки содержит уточняющую информацию. Текст варьируется в зависимости от проверяемого параметра

180005

 400 Значение превышает допустимое Весогабаритные характеристики груза превышают допустимые для приёма на терминалах города

180006

 400 Ошибка в параметрах запроса Детальное описание ошибки содержит уточняющую информацию. Текст варьируется в зависимости от проверяемого параметра

180007

 400 Недопустимое значение параметра Детальное описание ошибки содержит уточняющую информацию. Текст варьируется в зависимости от проверяемого параметра

180008

 400 Ошибка упрощенной отправки Детальное описание ошибки содержит уточняющую информацию. Текст варьируется в зависимости от проверяемого параметра

180009

 400 Ошибка оформления услуги Доставка в день заказа Детальное описание ошибки содержит уточняющую информацию. Текст варьируется в зависимости от проверяемого параметра

180010

 400 Ошибка оформления услуги Доставка в точное время Детальное описание ошибки содержит уточняющую информацию. Текст варьируется в зависимости от проверяемого параметра

180011

 400 Указан некорректный период работы Детальное описание ошибки содержит уточняющую информацию. Текст варьируется в зависимости от проверяемого параметра

180012

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

180013

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

180014

 400 Ошибка наложенного платежа Детальное описание ошибки содержит уточняющую информацию. Текст варьируется в зависимости от проверяемого параметра

180015

 400 Ошибка оформления услуги Детальное описание ошибки содержит уточняющую информацию. Текст варьируется в зависимости от проверяемого параметра

180016

 400 Ошибка при сохранении заявки Детальное описание ошибки содержит уточняющую информацию. Текст варьируется в зависимости от проверяемого параметра

180017

 400 Невозможно оформить заявку на указанное время Детальное описание ошибки содержит уточняющую информацию. Текст варьируется в зависимости от проверяемого параметра
Источник

Things don’t always go well when making your first API call, especially if you’re a beginner and it’s your first time integrating an API into another system. Often documentation is lacking in terms of api error status codes, since it’s easier to anticipate things going right, rather than things going wrong.

HTTP status codes can give you an idea of what was going on when you made your API call. The standardized status codes go from 100 to 511, and all have different meanings, but only the status codes from 400 to 511 reflect an error response. If you’re using Moesif, see a summary of the most likely API error status using this handy table.

Let’s look at the 10 most common HTTP status codes that indicate an error response, either on the client or the server-side.

Client-Side Status Codes

The 4XX group of status codes is usually related to client-side errors, but changes to the API can also cause them. Here are the 5 most common client-side status error codes and how to solve for them:

404 Not Found

This is by far the most common HTTP status code you can get. It indicates that the URL you used in your request doesn’t exist on the API server, or origin server. While this is a 4XX error, which usually means something on the client-side is wrong, this can also indicate a server problem. Sometimes API URL paths change after a version update, but sometimes they change because something on the server went wrong.

The best course of action is to check if you have a typo in your client code before checking if the API has issues.

This status code means you haven’t yet authenticated against the API. The API doesn’t know who you are and it won’t serve you.

For most APIs you need to sign up and get an API key. This key is then used inside an HTTP header field when you send a request, telling the API who you are.

This http status code is similar to the less common 407 Proxy Authentication Required, which means you haven’t authenticated with the proxy.

403 Forbidden

The forbidden status indicates that you don’t have permission to request that URL. You’re authenticated, but the user or role you’re authenticated for isn’t permitted to make the API request.

This also occurs when you have an authentication issue, like when using the wrong API key or trying to access features your subscription plan doesn’t allow for.

400 Bad Request

The 400 Bad Request error message is one of the most generic HTTP status codes. It implies that you did not correctly format your API request. If no additional error information is given in the response body, you have to check the docs. You could be missing a query, a field in the request body, or a header field could be wrong. It could also be that some of your request data might have incorrect syntax.

This is different from the 422 Unprocessable Entity error message, which appears when your request is correctly formatted, but cannot be processed.

429 Too Many Requests

Most API subscription plans have limits — the cheaper the plan, the fewer requests per second are allowed for your API key.

If you’re sending too many requests in a short amount of time, consider throttling them in your client. This response can also indicate that you hit a daily, weekly, or monthly limit on your account. Without implementing API analytics, it’s possible to reach these limits without receiving a push notification or email alert.

Sometimes an API sounds like a right fit until you see the limits, and suddenly it doesn’t work for your use case anymore. Check what’s part of your API subscription before integrating, otherwise you may run into problems weeks or months after integrating the API.

Server-Side Status Codes

The 5XX group of status codes usually return in response to a server error, but an invalid API call that should respond with a 4XX can also return a 5XX error if not caught correctly on the server. Here are the 5 most common errors and how to fix them:

500 Internal Server Error

This HTTP status code can mean anything really, but it usually indicates the API server crashed. It could have been caused by something related to your API call.

Double-check the docs to make sure you did everything right: query fields, body fields, headers, and format.

If that didn’t fix the problem, it might also have been related to an API update that introduced buggy code, or data the API loaded from an upstream service. In that case, your only cause of action is contacting the API’s support.

502 Bad Gateway

This response tells you that the server you were calling wasn’t the actual API server, but a gateway or proxy. The proxy server tries to call the API server in your name. This error response also indicates that the API server didn’t answer. This could be related to a network problem, or simply because the API server crashed, or was down for maintenance.

A “bad gateway” error is usually temporary and should be solved by the API provider, but you have to contact support if it persists.

503 Service Unavailable

The 503 Service Unavailable Status indicates a server error. Too many API requests were sent and now the API can’t handle any more of them. This problem solves itself when clients send fewer future requests, but it could also mean that the API provider didn’t plan enough resources for all of its customers.

If it fits your use case, you can make your client more resilient to this error by waiting to send another request. But if the error code keeps showing up, you have to contact the API provider.

504 Gateway Timed Out

Like the 502 Bad Gateway status, this response code tells you that the server you were calling is a proxy for the real API server. This time, the problem is the API server’s slow response.

This could be related to high network latency between the proxy and the API server. It could also mean that the API server takes too long to process your request.

To solve this problem, check if your request’s content could be related to that timeout. If you are requesting too much data or a calculation that takes too long, you should try and reduce it.

If you think your request is reasonable and the status doesn’t go away, contact support.

501 Not Implemented

The 501 Not Implemented status code is related to the HTTP method you used to request an URL. You can try a different HTTP method to make the request.

Usually, an HTTP request with an inappropriate method simply results in a 404 not found status. A not-implemented status implies that the method isn’t implemented “yet.” The API creator can use this status to tell the clients that this method will be available to them in future requests.

Monitoring HTTP Status Codes With Moesif

Moesif provides a rich set of monitoring and notification capabilities, so you can keep abreast of any HTTP status code errors automatically and gain deep insights from your error response trends.

Dashbaords showing 4xx and 5xx error trends

API calls are always tracked with user identity, so it’s easy to locate errors and solve them rapidly.

Automatic altering for status codes

Summary

Undoubtedly you’ll see many error codes when using APIs, but most have reasonable fixes. Some are related to server errors and some to client-side errors, where often one can cause the other.

Always try to read the docs and API notes thoroughly, so you don’t forget something while integrating. If things are simply broken, contact the API provider.

In some cases, the API provider won’t ever fix an issue for an API consumer. If you’re using a popular API you can also search the web for answers, especially StackOverflow, to find a fix for your error responses. Stay determined, and you’ll see your 200 ok status codes in no time.

Debug And Fix API Issues Quickly With High-cardinality API Logs

Learn More

Kay Ploesser

Kay Ploesser

Software Engineer and Web Enthusiast

Источник

Понравилась статья? Поделить с друзьями:
  • Api ошибка валидации какой код
  • App store ios 12 ошибка
  • Api ошибка 429
  • Api ошибка 403
  • App module exe системная ошибка