Uptimely
Все материалы

API

Как проверять API: авторизация, статус и ошибки endpoint

Настройка одного API endpoint: безопасный запрос, тестовый токен и ожидаемый код. Когда нужен многошаговый сценарий.

Команда Uptimely

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

Выберите безопасный запрос

Для первого монитора подойдёт GET к health endpoint или другой операции чтения. Успешная проверка должна подтверждать ровно выбранную функцию. Если health endpoint проверяет все внешние зависимости сразу, сбой одного партнёра может выглядеть как отказ всего приложения. Разделяйте независимые вопросы отдельными проверками.

Не используйте повторяемый POST создания реального заказа, списания или удаления. Для действий с записью нужны изолированная среда, специальные данные и явное управление последствиями.

Сопоставьте метод, статус и credentials

Этот ручной запрос показывает пример Bearer-авторизации. Подставьте свой адрес и передайте отдельный тестовый токен через окружение. Вымышленный адрес api.example.com здесь обозначает место для вашего API.

curl --silent --show-error --connect-timeout 5 --max-time 15 \
  --header "Authorization: Bearer $API_TOKEN" \
  https://api.example.com/health

Не включайте трассировку shell с секретным заголовком и не публикуйте журналы запросов. Заголовки и тело монитора доступны участникам проекта: личный production-токен администратора не подходит для такой интеграции.

Ожидаемый код по умолчанию — 200. Для контрактного 204 задайте 204; сам факт быстрого ответа не делает 401 или 500 успешным. Метод HEAD тоже не всегда эквивалентен GET — проверяйте именно метод вашего клиента.

Когда нужен сценарий из нескольких запросов

ВопросПодход
Работает один endpoint со стабильным токеном?HTTP-монитор, доступный на Free
Нужно получить токен, затем запросить профиль?API-сценарий на PRO, до пяти шагов, бета
Работает ли форма входа в интерфейсе?Браузерный Путь на PRO, бета

Обычный HTTP-монитор не обновляет токен запросом к другому endpoint. Для зависимых запросов используйте API-сценарий. Для кликов, ожидания элементов и проверки отрисованной страницы — Путь. Различайте структуру JSON-ответа и текст интерфейса браузера.

Доведите настройку до первого результата

В кабинете выберите API endpoint, задайте URL, метод, заголовки и ожидаемый статус. Для одиночного endpoint используется существующий тип HTTP, а не отдельный технический тип API. После сохранения откройте историю и изучите результат.

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

Как разбирать сбой

При 401 проверьте актуальность токена и права тестового пользователя. При тайм-ауте сопоставьте диагностику DNS, соединения и ожидания ответа. При неожиданном 200 проверьте, не вернулась ли HTML-страница входа вместо API. Не исправляйте монитор сменой ожидаемого кода на ошибочный только ради зелёного статуса.

Дальнейшие шаги: параметры API-проверки, диагностика HTTP и настройка HTTP-монитора.