Создание правила

Предварительные действия

Чтобы создать правило:

  1. Откройте рабочую область API Gateway (Разное → API Gateway) и нажмите карточку нужного шлюза. Откроется окно настройки шлюза API.

  2. Откройте вкладку Правила.

  3. Нажмите кнопку Создать правило.

  4. Заполните поля каждого из этапов мастера создания правила:

Тип правила

  1. Заполните поля:

    • Название — пользовательское имя правила.

    • Тип правила — один из вариантов использования правила:

      • Mock API — вернуть в ответ на запрос данные в формате, определенном пользователем, и не выполнять обращения к целевому хосту. Используется для имитации работы API, например, при тестировании.

      • Маршрутизация запросов — выполнить запрос на заданный URI подключения.

      • Разделение трафика — разделить запросы на несколько целевых хостов в заданном соотношении.

      • Перенаправление запросов (Redirect) — перенаправлять запросы на другой URL.

  2. Нажмите кнопку Продолжить.

Параметры правила

  1. Задайте параметры правила.

    Mock API

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

    Создать по одному из путей заглушку API для тестирования проекта. Заглушка отдает указанный ответ на запрос по данному URI вместо ответа от целевого хоста.

    Поля для заполнения
    • HTTP-методы — методы, запросы по которым будут обрабатываться правилом. Можно выбрать несколько значений.

    • Использовать WebSocket — использовать протокол WebSocket.

    • Тело ответа — JSON-объект, возвращаемый в ответ на запрос.

    • Задержка ответа — время задержки ответа в секундах. Поддерживаются только целочисленные значения. При отсутствии значения ответ возвращается сразу.

    • Статус ответа — HTTP-код возвращаемого ответа. Может быть установлен любой код ответа от 200 до 599. Если значение не задано, возвращается код ответа 200.

    • Заголовок content-type — значение, возвращаемое в заголовке content-type ответа. При отсутствии значения возвращается значение заголовка application/json.

    • Список URI — перечень URI, при запросе на которые будет использоваться создаваемое правило. Добавить новый URI можно кнопкой Добавить URI.

      В значении можно использоваться wildcard-символ (*) для обозначения произвольной части пути. Например, при добавлении URI «/foo*» правилом будут обработаны запросы на /foo//foo/a/foo/b и так далее.

    Маршрутизация запросов

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

    Создать по одному из путей заглушку API для тестирования проекта. Заглушка отдает указанный ответ на запрос по данному URI вместо ответа от целевого хоста.

    Поля для заполнения
    • HTTP-методы — методы, запросы по которым будут обрабатываться правилом. Можно выбрать несколько значений.

    • Использовать WebSocket — использовать протокол WebSocket.

    • Подключениеподключение к необходимому целевому хосту.

    • URI бэкенда — URI целевого хоста подключения, на который будет машрутизирован запрос.

    • Заголовок — заголовок, который будет добавлен к запросу при маршрутизации запроса к целевому хосту. Добавить новую пару заголовка и значения можно при помощи кнопки Добавить заголовок.

    • Значение — значение, которое будет передано в соответствующем заголовке при маршрутизации запроса к целевому хосту. Добавить новую пару заголовка и значения можно при помощи кнопки Добавить заголовок.

    • Опция Фильтровать по параметрам URL — позволяет добавить в URL запроса дополнительные параметры. При отправке такого запроса будет проверяться наличие и валидность параметра и его значения.

    • Список URI — перечень URI, при запросе на которые будет использоваться создаваемое правило. Добавить новый URI можно кнопкой Добавить URI.

      В значении можно использоваться wildcard-символ (*) для обозначения произвольной части пути. Например, при добавлении URI «/foo*» правилом будут обработаны запросы на /foo//foo/a/foo/b и так далее.

    Разделение трафика

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

    Провести A/B-тестирование. Например, проверить альтернативную версию бэкенда. Распределение трафика можно настроить так, чтобы доля запросов отправлялась на целевой хост, отличный от описанного в правиле.

    Поля для заполнения
    • HTTP-методы — методы, запросы по которым будут обрабатываться правилом. Можно выбрать несколько значений.

    • Использовать WebSocket — использовать протокол WebSocket.

    • Опция Blue-Green Release — позволяет настроить перенаправление запросов на разные подключения. Например, распределить запросы на старую (blue) и новую (green) версии приложения.

      Поля для заполнения
      • Заголовок — обязательное поле. Заголовок, по которому будет происходить маршрутизация. Добавить новую пару заголовка и значения можно при помощи кнопки Добавить заголовок.

      • Значение — обязательное поле. Значение, которое необходимо передать в соответствующем заголовке при маршрутизации запроса к целевому хосту.

      • Подключениеподключение к необходимому целевому хосту.

      • Опция Добавить группу позволяет настроить разделение трафика между бэкендами. Например, в группе 1 может быть указано подключение к бэкенду с текущей версией приложения, в группе 2 — подключение к бэкенду с новой версией. Распределение трафика на текущий и новый бэкенд происходит на основании указанных в API-запросе заголовков. Также внутри одной группы можно добавить несколько подключений для распределения запросов на разные подключения в соответствии с весом плеча.

    • Опция Разделение HTTP-методов по группам подключений позволяет настроить разделение трафика в зависимости от HTTP-метода. Например, разделить запросы на серверы, настроенные для записи и чтения.

    • Группа полей Список подключений для разделения трафика определяет правила распределения между заданными подключениями.

      • Подключениеподключение к необходимому целевому хосту.

      • Вес плеча — доля запросов, которые будут обработаны данным плечом. Доля является относительной в сравнении с другими плечами. Например, если значение веса «3» на первое плечо и «2» на второе, то первым плечом будет обработано 60% запросов (3/(3+2) * 100 %). Поле Вес плеча отображается, если добавлено больше одного адреса подключения.

    • Список URI — перечень URI, при запросе на которые будет использоваться создаваемое правило. Добавить новый URI можно кнопкой Добавить URI.

      В значении можно использоваться wildcard-символ (*) для обозначения произвольной части пути. Например, при добавлении URI «/foo*» правилом будут обработаны запросы на /foo//foo/a/foo/b и так далее.

    Перенаправление запросов (Redirect)

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

    Перенаправлять запросы на другой URL — например, на временную страницу-заглушку.

    Поля для заполнения
    • Список URI — перечень URI, при запросе на которые будет использоваться создаваемое правило. Добавить новый URI можно кнопкой Добавить URI.

      В значении можно использоваться wildcard-символ (*) для обозначения произвольной части пути. Например, при добавлении URI «/foo*» правилом будут обработаны запросы на /foo//foo/a/foo/b и так далее.

    • URL для переадресации — адрес, на который будут перенаправлены запросы

    • Переключатель Кодировка header Location в соответствии с RFC3986 активируйте при необходимости. Например, если в URL используются кириллические символы.

    • Переключатель Добавлять параметры запроса в Location активируйте при необходимости.

    В ответ на запрос к шлюзу API по указанным в правиле URI будет возвращаться код ответа HTTP 302 Moved Temporarily.

  2. Нажмите Продолжить.

  3. (опционально) Выберите один или несколько плагинов.

  4. Нажмите Создать.

  5. Чтобы включить правило, нажмите на переключатель в колонке Статус.