🛡️ Proxy Mock

Proxy Mock — это мощный и гибкий инструмент, сочетающий функции прокси-сервера и мок-сервера. Он позволяет эмулировать заранее настроенные API-эндпоинты, что делает его идеальным для тестирования и разработки интеграций.

📋 Основные возможности

Проксирование запросов:
Перенаправляйте запросы на указанный хост. Это позволяет интегрировать ваш сервис с реальными или тестовыми API, что удобно для отладки и проверки взаимодействий между системами.
Мокирование эндпоинтов:
Настраивайте и эмулируйте ответы для различных API с легкостью. Создавайте фиктивные ответы для специфичных эндпоинтов, что позволяет тестировать взаимодействие вашего приложения без необходимости обращаться к реальным сервисам.
Хранение данных о входящих запросах:
Сохраняйте информацию о всех входящих запросах для последующего анализа. Это позволяет отслеживать и управлять запросами, а также диагностировать проблемы в случае необходимости.
Легкость интеграции:
Удобное взаимодействие с другими сервисами через API. Ваш прокси-сервис может быть легко интегрирован в существующие системы, обеспечивая гибкость и расширяемость.

🚀 Начало работы

📦 Предварительные требования

Убедитесь, что на вашем компьютере установлены следующие компоненты:

Python >= 3.9
Poetry ~ 1.8.x

⚙️ Установка и запуск

Следуйте этим шагам, чтобы быстро развернуть проект в локальной среде разработки:

Установка зависимостей:

Установите виртуальное окружение и все необходимые зависимости:
```
poetry install --no-root
```
Активация виртуального окружения:

Активируйте ранее созданное виртуальное окружение:
```
poetry shell
```
Запуск сервиса:

Используйте Makefile для запуска сервиса:
```
sudo apt install make
make run
```

🐳 Запуск в Docker

Для быстрого развертывания сервиса в изолированном окружении используйте Docker.

Сборка Docker-образа:

Чтобы собрать Docker-образ и запустить сервис, выполните следующую команду:
```
make docker_run
```
Доступ к сервису:

После успешного запуска сервис будет доступен по адресу:
```
http://localhost:5000
```

📡 API

Proxy Mock предоставляет простой и интуитивно понятный API для взаимодействия с сервером и управления конфигурациями мок-запросов.

1. `/status` (GET)

Проверка доступности сервера прокси-мока

Этот эндпоинт используется для проверки текущего состояния сервера и его доступности. Также он возвращает информацию о версии сервера.

URL: /status
Метод: GET

Ответ:

Успешный ответ:
- Код ответа: 200 OK
- Тип контента: application/json
- Тело ответа:
```
{
    "success": true,
    "version": "1.0.0"  // Версия сервера
}
```
- Описание полей:
  - success: boolean
    Параметр, указывающий на успешное выполнение запроса. Значение всегда true, если сервер доступен.
  - version: string
    Версия текущего сервера. Может быть полезна для определения актуальности сервера и его компонентов.

2. `/configure_mock` (POST)

Конфигурация мок-запроса в прокси-моке

Этот эндпоинт используется для настройки мок-запросов в прокси-моке. Можно указать путь, данные мока, дополнительную информацию, проксирующий хост и таймаут.

URL: /configure_mock
Метод: POST
Тип контента: application/json

Тело запроса:

JSON:
- path (обязательный) — string:
  Путь, по которому будет применен мок-запрос.
- mock_data — dict:
  Данные мок-ответа:
  - body — string | dict | list:
    Тело ответа, которое будет возвращено при совпадении пути.
  - status_code — integer:
    Код состояния ответа.
  - headers — dict:
    Заголовки ответа.
- extra_info — dict (опционально):
  Дополнительная информация о мок-запросе.
- proxy_host — string (опционально):
  URL проксирующего хоста, на который будет перенаправлен запрос.
- timeout — float (опционально):
  Время задержки перед отправкой ответа, в секундах.

Пример запроса:

{
    "path": "/test/endpoint",
    "mock_data": {
        "body": {
            "message": "Hello, World!"
        },
        "status_code": 200,
        "headers": {
            "Content-Type": "application/json"
        }
    },
    "extra_info": {
        "service": "example_service"
    },
    "proxy_host": "http://example.com",
    "timeout": 1.5
}

Ответ:

Успешный ответ:

Код ответа: 200 OK
Тип контента: application/json

Тело ответа:

{
    "data": {},  // Записанные данные
    "path": "test/endpoint",
    "success": true
}

Неуспешный ответ:
- Код ответа: 400 BAD REQUEST
- Тип контента: application/json
- Тело ответа:
```
{
    "success": false,
    "error": "Parameter 'path' is always required"
}
```
Примечание: В случае ошибки, возвращается сообщение, описывающее проблему с запросом, например, отсутствие обязательного параметра path.

3. `/configure_mock/binary` (POST)

Конфигурация мок-запроса с бинарным содержимым в прокси-моке

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

URL: /configure_mock/binary
Метод: POST
Тип контента: binary/app

Тело запроса:

BYTES:
Бинарные данные должны содержать JSON-словарь с конфигурацией мока:
- path (обязательный) — string:
  Путь, по которому будет применен мок-запрос.
- mock_data — dict:
  Данные мок-ответа:
  - body — bytes:
    Тело ответа, которое будет возвращено при совпадении пути.
  - status_code — integer:
    Код состояния ответа.
  - headers — dict:
    Заголовки ответа.
- extra_info — dict (опционально):
  Дополнительная информация о мок-запросе.
- proxy_host — string (опционально):
  URL проксирующего хоста, на который будет перенаправлен запрос.
- timeout — float (опционально):
  Время задержки перед отправкой ответа, в секундах.

Пример бинарного запроса:

Бинарные данные запроса должны содержать следующий словарь:

{
    "path": "/test/endpoint",
    "mock_data": {
        "body": {
            "message": "byte data"
        },
        "status_code": 200,
        "headers": {
            "Content-Type": "application/json"
        }
    },
    "extra_info": {
        "service": "example_service"
    },
    "proxy_host": "http://example.com",
    "timeout": 1.5
}

Ответ:

Успешный ответ:

Код ответа: 200 OK
Тип контента: application/json

Тело ответа:

{
    "data": {},  // Записанные данные
    "path": "/test/endpoint",
    "success": true
}

Неуспешный ответ:
- Код ответа: 400 BAD REQUEST
- Тип контента: application/json
- Тело ответа:
```
{
    "success": false,
    "error": "Parameter 'path' is always required"
}
```
Примечание: В случае ошибки, возвращается сообщение, описывающее проблему с запросом, например, отсутствие обязательного параметра path.

4. `/traffic/clean` (POST)

Очистка хранилища параметров запросов

Этот эндпоинт очищает хранилище параметров запросов. Можно указать параметр service для фильтрации очистки по конкретному сервису.

URL: /traffic/clean
Метод: POST

Ответ:

Успешный ответ:
- Код ответа: 200 OK
- Тип контента: application/json
- Тело ответа:
```
{
    "data": [],
    "success": true
}
```

5. `/storage/clean` (POST)

Очистка хранилища моков

Этот эндпоинт очищает хранилище моков. Можно указать параметр path для фильтрации очистки по конкретному пути.

URL: /storage/clean
Метод: POST
Query-параметры:
- path (опциональный) — str:
  Если указан, будет очищено только хранилище моков для указанного пути.

Ответ:

Успешный ответ:
- Код ответа: 200 OK
- Тип контента: application/json
- Тело ответа:
```
{
    "data": {},
    "success": true
}
```
Примечание: В случае ошибки (например, если указанный путь не найден), возвращается ошибка "success": false.

6. `/storage` (GET)

Вывод хранилища моков

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

URL: /storage
Метод: GET
Query-параметры:
- path (опциональный) — str:
  Фильтрует результаты по указанному пути. Если параметр не указан, будут возвращены все моки.

Ответ:

Успешный ответ:

Код ответа: 200 OK
Тип контента: application/json

Тело ответа:

{
    "data": {},  // Объект с данными моков для указанного пути или всех моков
    "success": true
}

Примечание: В поле data будет представлен JSON-объект со всеми мока, соответствующими указанному пути или все моки, если путь не задан.

7. `/traffic` (GET)

Вывод хранилища параметров запросов

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

URL: /traffic
Метод: GET

Ответ:

Успешный ответ:

Код ответа: 200 OK
Тип контента: application/json

Тело ответа:

{
    "data": [],  // Массив объектов с данными о запросах
    "success": true
}

Примечание: В поле data будет представлен массив объектов, содержащих информацию о каждом запросе, который был перехвачен и сохранен системой.

8. `/<path:path>` (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS)

Перехват всех входящих запросов

Этот эндпоинт обрабатывает все запросы, поступающие на прокси-мок, вне зависимости от их пути. После перехвата запросов, сервер проверяет, существует ли заранее сконфигурированный ответ для данного пути.

Поддерживаемые HTTP-методы:

GET
POST
PUT
DELETE
PATCH
HEAD
OPTIONS

Логика обработки запроса:

Если заранее сконфигурированный ответ найден:
- Задержка ответа (таймаут):
  Если для данного запроса был настроен таймаут, сервер выполнит задержку перед отправкой ответа. Задержка будет соответствовать указанному времени ожидания (в секундах).
- Заголовки ответа:
  Если для данного запроса были заранее сохранены заголовки, они будут отправлены вместе с ответом.
- Ответ без проксирования:
  Если проксирующий хост не указан, сервер вернет заранее подготовленный ответ:
  - Код ответа: Заранее подготовленный код ответа (например, 200).
  - Тело ответа: Заранее подготовленные данные ответа, такие как JSON-объект или HTML-страница.
- Ответ с проксированием на внешний хост:
  Если для данного запроса указан проксирующий хост, запрос будет перенаправлен на внешний сервис. Клиент получит ответ от этого внешнего хоста:
  - Код ответа: Код состояния ответа от внешнего хоста (например, 200, 404, 500).
  - Тело ответа: Содержимое тела ответа, полученное от внешнего хоста.
Если заранее сконфигурированный ответ не найден:

Если для запроса не был настроен мок-ответ, возвращается ошибка:
- Код ответа: 404 NOT FOUND
- Тип контента: application/json
- Тело ответа:
```
{
    "error": "Не найден мок /mock_path"
}
```

Name		Name	Last commit message	Last commit date
Latest commit History 5 Commits
client		client
proxy_mock		proxy_mock
tests		tests
.gitignore		.gitignore
Dockerfile		Dockerfile
Makefile		Makefile
README.md		README.md
poetry.lock		poetry.lock
pyproject.toml		pyproject.toml
setup.cfg		setup.cfg

ivi-ru/proxy_mock

Folders and files

Latest commit

History

Repository files navigation

🛡️ Proxy Mock

📋 Основные возможности

🚀 Начало работы

📦 Предварительные требования

⚙️ Установка и запуск

🐳 Запуск в Docker

📡 API

1. /status (GET)

Проверка доступности сервера прокси-мока

Ответ:

2. /configure_mock (POST)

Конфигурация мок-запроса в прокси-моке

Тело запроса:

Пример запроса:

Ответ:

3. /configure_mock/binary (POST)

Конфигурация мок-запроса с бинарным содержимым в прокси-моке

Тело запроса:

Пример бинарного запроса:

Ответ:

4. /traffic/clean (POST)

Очистка хранилища параметров запросов

Ответ:

5. /storage/clean (POST)

Очистка хранилища моков

Ответ:

6. /storage (GET)

Вывод хранилища моков

Ответ:

7. /traffic (GET)

Вывод хранилища параметров запросов

Ответ:

8. /<path:path> (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS)

Перехват всех входящих запросов

Поддерживаемые HTTP-методы:

Логика обработки запроса:

About

Topics

Resources

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Uh oh!

Languages

1. `/status` (GET)

2. `/configure_mock` (POST)

3. `/configure_mock/binary` (POST)

4. `/traffic/clean` (POST)

5. `/storage/clean` (POST)

6. `/storage` (GET)

7. `/traffic` (GET)

8. `/<path:path>` (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS)

Packages