Сценарий использования

Ломайте свой API намеренно.

Направьте любой клиент на прокси, затем подмените ответ на 500, приостановите запрос на лету или экспортируйте всё произошедшее как HAR для коллеги.

An Android phone, a browser and a backend server stream traffic into a central proxy hexagon on port 8888; one stream passes a block-and-script rule gate and comes out transformed, then one live stream flows on into a dashboard feed with green status codes. A globe marks upstream proxy routing. android browser server {} rules :8888 upstream live 200 201 200

Проблема

Воспроизвести баг API означает подделать бэкенд

Медленный эндпоинт, некорректное тело ошибки, гонка между двумя вызовами — всё это трудно вызвать по требованию с реального сервера.

Для бэкенд- и full-stack-инженеров, разрабатывающих или тестирующих API-клиент — мобильное приложение, фронтенд, CLI, CI-задачу — которым нужно видеть и контролировать точные байты на проводе, а не только ответ, возвращаемый SDK.

proxy-server Busymate находится между вашим клиентом и настоящим API. Каждый запрос захватывается в реальном времени, и тот же движок правил блокировки/подмены/сброса, что работает на iOS и в захвате Chrome, работает и здесь — вы можете ответить на реальный запрос заготовленным, или сбросить его полностью, не трогая бэкенд.

Как это решается

Один URL PAC, весь набор инструментов за ним

Никакого SDK, никакого агента для установки — любой клиент, который можно направить на прокси, уже интегрирован.

Подменяйте, блокируйте или сбрасывайте на проводе

Отвечайте на подходящий запрос собственным статусом, заголовками и телом — или сбрасывайте его — с помощью правил, работающих прямо в прокси, ещё до того, как запрос дойдёт до настоящего API.

Точка останова, редактирование, повтор

Приостановите запрос на лету, отредактируйте необработанный HTTP вручную, затем продолжите или отправьте повторно — воспроизведите гонку или некорректный payload без единой строки тестового кода.

Экспорт в HAR или доступ через REST

Экспортируйте точный обмен как HAR-файл для коллеги или отчёта об ошибке, либо получите те же захваченные данные через простой REST API на базе PostgREST — SDK не требуется ни в том, ни в другом случае.

Задействованные поверхности
  • Proxy
  • Dashboard
  • REST
  • MCP

Пошаговое руководство

От нестабильного клиента к воспроизводимому баг-репорту

Без изменений кода ни с одной из сторон.

  1. 01

    Направьте клиент на прокси

    Настройте клиент — телефон, браузер, бэкенд-сервис, CI-задачу — с помощью единого URL автоконфигурации PAC. Трафик начинает поступать сразу.

  2. 02

    Воспроизведите сбой

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

  3. 03

    Экспортируйте или запросите результат

    Экспортируйте обмен как HAR для прикрепления к отчёту об ошибке, или получите те же захваченные записи из вашего набора тестов через REST API.

На прокси

Как это работает на проводе

Один прокси стоит между вашим клиентом и настоящим API; правила выполняются внутри него.

  1. 01

    Направьте клиент на свой прокси

    У каждого устройства есть своя прокси-идентичность и URL автонастройки прокси. Вставьте этот URL в настройки Wi-Fi телефона, профиль браузера или переменную HTTP-прокси, которую читает бэкенд или задача CI, — и его запросы сразу начинают попадать в ленту дашборда.

  2. 02

    Напишите правило или поставьте запрос на паузу

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

  3. 03

    Передайте обмен кому-то ещё

    Экспортируйте запрос и ответ в файл HAR для отчёта об ошибке или читайте те же захваченные записи из тестового набора через REST API. И то, и другое содержит точные байты, прошедшие по проводу, а не интерпретацию SDK.

ЧЗВ

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

Нужен ли моему клиенту SDK или изменение кода?

Нет. Всё, что можно направить на HTTP-прокси, уже интегрировано — телефоны, браузеры, бэкенд-сервисы, задачи CI. Прокси берёт на себя захват и правила; ваш клиент продолжает говорить с тем, что считает настоящим API.

Можно замокать только один эндпоинт, оставив остальные настоящими?

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

Блокирует ли точка останова остальной трафик?

Нет. Останавливается только подходящий запрос; всё остальное продолжает идти. Продолжите, отредактируйте или отправьте заново, когда будете готовы, и клиент увидит результат так, будто ответил сервер.

Могут ли мои тесты читать захваченный трафик?

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

Хватит подделывать бэкенд — управляйте настоящим проводом

Направьте свой первый клиент на прокси и подмените, сломайте или повторно отправьте свой первый запрос за считанные минуты.

Ask your mate