Проверяйте критичные endpoint-ы REST API по расписанию: метод, ожидаемый статус, таймаут и содержимое JSON, если одного HTTP-ответа недостаточно.
Сайт может открываться, а REST API уже быть недоступным для мобильного приложения, личного кабинета, партнёров или внутренних интеграций.
UpWatch позволяет добавлять HTTP-проверки endpoint-ов, выбирать метод, контролировать ожидаемый статус ответа, таймаут и редиректы.
Если endpoint возвращает JSON, можно добавить JSON-проверки и убедиться, что API не просто отвечает, а отдаёт ожидаемые данные.
Начните с маршрутов, без которых продукт фактически не работает: вход, профиль, заказ, оплата, интеграции.
Для каждого endpoint-а укажите HTTP-метод, ожидаемый код ответа, таймаут и правила редиректов.
Если API может вернуть 200 с неверными данными, проверяйте конкретные поля в JSON-ответе.
Инциденты по API лучше отправлять туда, где их увидит разработчик или дежурный специалист.
Endpoint может вернуть успешный HTTP-статус, но внутри ответа будет пустой список, неверный статус операции или отсутствующее поле.
Для критичных API нужно проверять минимум два слоя: доступность endpoint-а и содержимое ответа.
UpWatch закрывает этот базовый сценарий: HTTP-проверка, JSON-правила, инциденты, история и уведомления.
В UpWatch для HTTP-мониторов поддерживаются разрешённые HTTP-методы, включая POST. При этом не нужно обещать полноценные пользовательские сценарии или сложные цепочки запросов.
Можно использовать заголовки, если endpoint допускает такой способ проверки. Полноценный сценарий логина с получением токена перед каждой проверкой не нужно считать реализованным.
Когда одного HTTP-статуса недостаточно: например, API отвечает 200, но поле status, enabled, count или result содержит неверное значение.
Базовая страница про HTTP- и API-проверки.
Контроль содержимого ответа API.
Контроль endpoint-ов, статусов и таймаутов.
