Ссылка на условия

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee
X.info

Условия позволяют API-прокси вести себя динамически во время выполнения. Условия определяют операции над переменными, которые оцениваются конвейером обработки Apigee Edge. Условные операторы являются логическими и всегда оцениваются как true или false .

Обзор условий

В этом разделе описывается, как и где использовать условные операторы в Edge. Кроме того, в следующих разделах описывается синтаксис:

Структура условных операторов

Базовая структура условного оператора выглядит следующим образом:

<Condition>variable.name operator "value"</Condition>

Например:

<Condition>request.verb = "GET"</Condition>

Условия можно комбинировать с помощью оператора И, чтобы одновременно применять несколько условий. Например, следующие условия будут true только в том случае, если URI запроса совпадает с /statuses , а HTTP-метод запроса — GET :

<Condition>(proxy.pathsuffix MatchesPath "/statuses") and (request.verb = "GET")</Condition>

Где можно использовать условные операторы

Для управления поведением можно использовать условия в следующих случаях:

исполнение политики

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

В следующем примере выполняется условное преобразование XML в JSON на основе заголовка Accept :

<Step>
  <Condition>request.header.accept = "application/json"</Condition>
  <Name>XMLToJSON</Name>
</Step>

Выполнение потока

С помощью условных операторов можно управлять выполнением именованных потоков в ProxyEndpoints и TargetEndpoints. Обратите внимание, что условному выполнению подлежат только «именованные» потоки. Предварительные и последующие потоки (как запросы, так и ответы) в ProxyEndpoints и TargetEndpoints выполняются для каждой транзакции, обеспечивая, таким образом, безусловную «безопасность от сбоев».

Например, для выполнения условного запроса в зависимости от HTTP-глагола запроса и условного ответа в зависимости от (потенциального) кода состояния HTTP, представляющего ошибку:

<Flow name="GetRequests">
  <Condition>request.verb = "GET"</Condition>
  <Request>
    <Step>
      <Condition>request.path MatchesPath "/statuses/**"</Condition>
      <Name>StatusesRequestPolicy</Name>
    </Step>
  </Request>
  <Response>
    <Step>
      <Condition>(response.status.code = 503) or (response.status.code = 400)</Condition>
      <Name>MaintenancePolicy</Name>
    </Step>
  </Response>
</Flow>

выбор маршрута до конечной точки цели

Используя условные операторы, вы можете управлять целевой конечной точкой, вызываемой конфигурацией прокси-сервера. Правило маршрутизации перенаправляет запрос на конкретную целевую конечную точку. Если доступно более одной целевой конечной точки, правило маршрутизации проверяется на соответствие условию, и если оно истинно, запрос перенаправляется на указанную целевую конечную точку.

Например, для условной маршрутизации сообщений к указанным целевым конечным точкам на основе Content-Type :

<RouteRule name="default">
 <!--this routing executes if the header indicates that this is an XML call. If true, the call is routed to the endpoint XMLTargetEndpoint-->
  <Condition>request.header.Content-Type = "text/xml"</Condition>
  <TargetEndpoint>XmlTargetEndpoint</TargetEndpoint>
</RouteRule>

Дополнительную информацию см. в разделе «Переменные и условия потока» .

Выражения пути

Для сопоставления URI-путей используются выражения пути, где символ "*" обозначает один элемент пути, а символ "**" — несколько уровней URI.

Например:

Шаблон Совпали примеры путей URI.
/*/a/ /x/a/ или /y/a/
/*/a/* /x/a/b или /y/a/foo
/*/a/** /x/a/b/c/d
/*/a/*/feed/ /x/a/b/feed/ или /y/a/foo/feed/
/a/**/feed/** /a/b/feed/rss/1234

Символ % рассматривается как экранирующий символ. Шаблон %{user%} соответствует {user} , но не user .

Переменные

В условных операторах можно использовать как встроенные переменные потока, так и пользовательские переменные. Для получения дополнительной информации см.:

Операторы

При использовании операторов соблюдайте следующие ограничения:

  • Операторы нельзя использовать в качестве имен переменных.
  • Перед и после оператора необходимо поставить пробел.
  • Чтобы включить оператор в переменную, имя переменной должно быть заключено в одинарные кавычки. Например, 'request.header.help!me' .
  • Арифметические операторы ( + * - / % ) не поддерживаются.
  • В Java для операторов используется порядок приоритета .
  • Apigee Edge использует регулярные выражения, реализованные в java.util.regex .

В таблице ниже перечислены поддерживаемые операторы. В выражениях можно использовать символ или слово:

Символ Слово Описание
! Not , not Унарный оператор (принимает один входной сигнал)
= Equals , Is Равно (с учетом регистра)
!= NotEquals , IsNot Не равно (регистр имеет значение)
:= EqualsCaseInsensitive Равно, но регистр нечувствителен.
> или &gt; GreaterThan Больше, чем. Если вы используете > при определении условия в пользовательском интерфейсе Edge, оно преобразуется в >.
>= или &gt;= GreaterThanOrEquals Больше или равно. Если при определении условия в пользовательском интерфейсе Edge используется >=, оно преобразуется в >=.
&lt; LesserThan Меньше, чем. Пользовательский интерфейс Edge не поддерживает символ "<".
&lt;= LesserThanOrEquals Меньше или равно. Пользовательский интерфейс Edge не поддерживает символ <=.
&& And , and И
|| Or Оператор ИЛИ не чувствителен к регистру. Например, OR , Or и or все они допустимы.
() Группирует выражение. Конструктор ( открывает выражение, а скобка ) закрывает его.
~~ JavaRegex

Соответствует регулярному выражению, совместимому javax.util.regex . Совпадение чувствительно к регистру. Примеры см. в разделе «Сопоставление шаблонов в условных операторах» .

~ Matches , Like Сопоставляет шаблон в стиле glob, используя символ подстановки "*". Сопоставление чувствительно к регистру. Примеры см. в разделе "Сопоставление шаблонов с использованием условий" .
~/ MatchesPath , LikePath Соответствует выражению пути. Сопоставление чувствительно к регистру. Примеры см. в разделе «Сопоставление с шаблонами с использованием условных операторов» .
=| StartsWith Сопоставляет первые символы строки. Сопоставление чувствительно к регистру.

Операнды

Apigee Edge адаптирует операнды к общему типу данных перед их сравнением. Например, если код состояния ответа равен 404, то выражения response.status.code = "400" и response.status.code = 400 будут эквивалентны.

Для числовых операндов тип данных интерпретируется как целое число, если значение не завершается следующим образом:

  • "f" или "F" (например, плавающий элемент, 3.142f, 91.1F)
  • "d" или "D" (удвоить, например, 3.142d, 100.123D)
  • «l» или «L» (длинный, например, 12321421312L)

В этих случаях система выполняет адаптации, показанные в следующей таблице (где RHS обозначает правую сторону уравнения, а LHS — левую):

правая сторона, левая сторона Логический Целое число Длинный Плавать Двойной Нить Сравнимый Объект
Логический Логический Целое число Длинный Плавать Двойной Нить -
Целое число Целое число Целое число Длинный Плавать Двойной Нить Сравнимый -
Длинный Длинный Длинный Длинный Плавать Двойной Нить Сравнимый -
Плавать Плавать Плавать Плавать Плавать Двойной Нить Сравнимый -
Двойной Двойной Двойной Двойной Двойной Двойной Нить Сравнимый -
Нить Нить Нить Нить Нить Нить Нить Сравнимый -
Сравнимый Сравнимый Сравнимый Сравнимый Сравнимый Сравнимый Сравнимый Сравнимый -
Объект - - - - - - - -

Нулевые операнды

В следующей таблице показано, принимают ли условия значение true или false , когда значения в левой (ЛС) и/или правой (ПС) частях указанного операнда равны нулю:

Оператор LHS null Правая часть равна нулю Левая и правая части нулевые
= , == , := ЛОЖЬ ЛОЖЬ истинный
=| ЛОЖЬ ЛОЖЬ ЛОЖЬ
!= истинный истинный ЛОЖЬ
> или &gt; истинный ЛОЖЬ ЛОЖЬ
>= или &gt;= ЛОЖЬ истинный истинный
&lt; истинный ЛОЖЬ ЛОЖЬ
&lt;= истинный ЛОЖЬ истинный
~ ЛОЖЬ Н/Д ЛОЖЬ
~~ ЛОЖЬ Н/Д ЛОЖЬ
!~ истинный ЛОЖЬ ЛОЖЬ
~/ ЛОЖЬ Н/Д ЛОЖЬ

Буквалы

Помимо строковых и числовых литералов, в условных операторах можно использовать следующие литералы:

  • null
  • true
  • false

Например:

  • request.header.host is null
  • flow.cachehit is true

Примеры

<RouteRule name="default">
     <Condition>request.header.content-type = "text/xml"</Condition>
     <TargetEndpoint>XmlTargetEndpoint</TargetEndpoint>
</RouteRule>
<Step>
    <Condition>response.status.code = 503</Condition>
    <Name>MaintenancePolicy</Name>
</Step>
<Flow name="GetRequests">
    <Condition>response.verb="GET"</Condition>
    <Request>
        <Step>
            <Condition>request.path ~ "/statuses/**"</Condition>
            <Name>StatusesRequestPolicy</Name>
        </Step>
    </Request>
    <Response>
        <Step>
            <Condition>(response.status.code = 503) or (response.status.code = 400)</Condition>
            <Name>MaintenancePolicy</Name>
        </Step>
    </Response>
</Flow>
,

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee
X.info

Условия позволяют API-прокси вести себя динамически во время выполнения. Условия определяют операции над переменными, которые оцениваются конвейером обработки Apigee Edge. Условные операторы являются логическими и всегда оцениваются как true или false .

Обзор условий

В этом разделе описывается, как и где использовать условные операторы в Edge. Кроме того, в следующих разделах описывается синтаксис:

Структура условных операторов

Базовая структура условного оператора выглядит следующим образом:

<Condition>variable.name operator "value"</Condition>

Например:

<Condition>request.verb = "GET"</Condition>

Условия можно комбинировать с помощью оператора И, чтобы одновременно применять несколько условий. Например, следующие условия будут true только в том случае, если URI запроса совпадает с /statuses , а HTTP-метод запроса — GET :

<Condition>(proxy.pathsuffix MatchesPath "/statuses") and (request.verb = "GET")</Condition>

Где можно использовать условные операторы

Для управления поведением можно использовать условия в следующих случаях:

исполнение политики

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

В следующем примере выполняется условное преобразование XML в JSON на основе заголовка Accept :

<Step>
  <Condition>request.header.accept = "application/json"</Condition>
  <Name>XMLToJSON</Name>
</Step>

Выполнение потока

С помощью условных операторов можно управлять выполнением именованных потоков в ProxyEndpoints и TargetEndpoints. Обратите внимание, что условному выполнению подлежат только «именованные» потоки. Предварительные и последующие потоки (как запросы, так и ответы) в ProxyEndpoints и TargetEndpoints выполняются для каждой транзакции, обеспечивая, таким образом, безусловную «безопасность от сбоев».

Например, для выполнения условного запроса в зависимости от HTTP-глагола запроса и условного ответа в зависимости от (потенциального) кода состояния HTTP, представляющего ошибку:

<Flow name="GetRequests">
  <Condition>request.verb = "GET"</Condition>
  <Request>
    <Step>
      <Condition>request.path MatchesPath "/statuses/**"</Condition>
      <Name>StatusesRequestPolicy</Name>
    </Step>
  </Request>
  <Response>
    <Step>
      <Condition>(response.status.code = 503) or (response.status.code = 400)</Condition>
      <Name>MaintenancePolicy</Name>
    </Step>
  </Response>
</Flow>

выбор маршрута до конечной точки цели

Используя условные операторы, вы можете управлять целевой конечной точкой, вызываемой конфигурацией прокси-сервера. Правило маршрутизации перенаправляет запрос на конкретную целевую конечную точку. Если доступно более одной целевой конечной точки, правило маршрутизации проверяется на соответствие условию, и если оно истинно, запрос перенаправляется на указанную целевую конечную точку.

Например, для условной маршрутизации сообщений к указанным целевым конечным точкам на основе Content-Type :

<RouteRule name="default">
 <!--this routing executes if the header indicates that this is an XML call. If true, the call is routed to the endpoint XMLTargetEndpoint-->
  <Condition>request.header.Content-Type = "text/xml"</Condition>
  <TargetEndpoint>XmlTargetEndpoint</TargetEndpoint>
</RouteRule>

Дополнительную информацию см. в разделе «Переменные и условия потока» .

Выражения пути

Для сопоставления URI-путей используются выражения пути, где символ "*" обозначает один элемент пути, а символ "**" — несколько уровней URI.

Например:

Шаблон Совпали примеры путей URI.
/*/a/ /x/a/ или /y/a/
/*/a/* /x/a/b или /y/a/foo
/*/a/** /x/a/b/c/d
/*/a/*/feed/ /x/a/b/feed/ или /y/a/foo/feed/
/a/**/feed/** /a/b/feed/rss/1234

Символ % рассматривается как экранирующий символ. Шаблон %{user%} соответствует {user} , но не user .

Переменные

В условных операторах можно использовать как встроенные переменные потока, так и пользовательские переменные. Для получения дополнительной информации см.:

Операторы

При использовании операторов соблюдайте следующие ограничения:

  • Операторы нельзя использовать в качестве имен переменных.
  • Перед и после оператора необходимо поставить пробел.
  • Чтобы включить оператор в переменную, имя переменной должно быть заключено в одинарные кавычки. Например, 'request.header.help!me' .
  • Арифметические операторы ( + * - / % ) не поддерживаются.
  • В Java для операторов используется порядок приоритета .
  • Apigee Edge использует регулярные выражения, реализованные в java.util.regex .

В таблице ниже перечислены поддерживаемые операторы. В выражениях можно использовать символ или слово:

Символ Слово Описание
! Not , not Унарный оператор (принимает один входной сигнал)
= Equals , Is Равно (с учетом регистра)
!= NotEquals , IsNot Не равно (регистр имеет значение)
:= EqualsCaseInsensitive Равно, но регистр нечувствителен.
> или &gt; GreaterThan Больше, чем. Если вы используете > при определении условия в пользовательском интерфейсе Edge, оно преобразуется в >.
>= или &gt;= GreaterThanOrEquals Больше или равно. Если при определении условия в пользовательском интерфейсе Edge используется >=, оно преобразуется в >=.
&lt; LesserThan Меньше, чем. Пользовательский интерфейс Edge не поддерживает символ "<".
&lt;= LesserThanOrEquals Меньше или равно. Пользовательский интерфейс Edge не поддерживает символ <=.
&& And , and И
|| Or Оператор ИЛИ не чувствителен к регистру. Например, OR , Or и or все они допустимы.
() Группирует выражение. Конструктор ( открывает выражение, а скобка ) закрывает его.
~~ JavaRegex

Соответствует регулярному выражению, совместимому с javax.util.regex . Совпадение чувствительно к регистру. Примеры см. в разделе «Сопоставление шаблонов в условных операторах» .

~ Matches , Like Сопоставляет шаблон в стиле glob, используя символ подстановки "*". Сопоставление чувствительно к регистру. Примеры см. в разделе "Сопоставление шаблонов с использованием условий" .
~/ MatchesPath , LikePath Соответствует выражению пути. Сопоставление чувствительно к регистру. Примеры см. в разделе «Сопоставление с шаблонами с использованием условных операторов» .
=| StartsWith Сопоставляет первые символы строки. Сопоставление чувствительно к регистру.

Операнды

Apigee Edge адаптирует операнды к общему типу данных перед их сравнением. Например, если код состояния ответа равен 404, то выражения response.status.code = "400" и response.status.code = 400 будут эквивалентны.

Для числовых операндов тип данных интерпретируется как целое число, если значение не завершается следующим образом:

  • "f" или "F" (например, плавающий элемент, 3.142f, 91.1F)
  • "d" или "D" (удвоить, например, 3.142d, 100.123D)
  • «l» или «L» (длинный, например, 12321421312L)

В этих случаях система выполняет адаптации, показанные в следующей таблице (где RHS обозначает правую сторону уравнения, а LHS — левую):

правая сторона, левая сторона Логический Целое число Длинный Плавать Двойной Нить Сравнимый Объект
Логический Логический Целое число Длинный Плавать Двойной Нить -
Целое число Целое число Целое число Длинный Плавать Двойной Нить Сравнимый -
Длинный Длинный Длинный Длинный Плавать Двойной Нить Сравнимый -
Плавать Плавать Плавать Плавать Плавать Двойной Нить Сравнимый -
Двойной Двойной Двойной Двойной Двойной Двойной Нить Сравнимый -
Нить Нить Нить Нить Нить Нить Нить Сравнимый -
Сравнимый Сравнимый Сравнимый Сравнимый Сравнимый Сравнимый Сравнимый Сравнимый -
Объект - - - - - - - -

Нулевые операнды

В следующей таблице показано, принимают ли условия значение true или false , когда значения в левой (ЛС) и/или правой (ПС) частях указанного операнда равны нулю:

Оператор LHS null Правая часть равна нулю Левая и правая части нулевые
= , == , := ЛОЖЬ ЛОЖЬ истинный
=| ЛОЖЬ ЛОЖЬ ЛОЖЬ
!= истинный истинный ЛОЖЬ
> или &gt; истинный ЛОЖЬ ЛОЖЬ
>= или &gt;= ЛОЖЬ истинный истинный
&lt; истинный ЛОЖЬ ЛОЖЬ
&lt;= истинный ЛОЖЬ истинный
~ ЛОЖЬ Н/Д ЛОЖЬ
~~ ЛОЖЬ Н/Д ЛОЖЬ
!~ истинный ЛОЖЬ ЛОЖЬ
~/ ЛОЖЬ Н/Д ЛОЖЬ

Буквалы

Помимо строковых и числовых литералов, в условных операторах можно использовать следующие литералы:

  • null
  • true
  • false

Например:

  • request.header.host is null
  • flow.cachehit is true

Примеры

<RouteRule name="default">
     <Condition>request.header.content-type = "text/xml"</Condition>
     <TargetEndpoint>XmlTargetEndpoint</TargetEndpoint>
</RouteRule>
<Step>
    <Condition>response.status.code = 503</Condition>
    <Name>MaintenancePolicy</Name>
</Step>
<Flow name="GetRequests">
    <Condition>response.verb="GET"</Condition>
    <Request>
        <Step>
            <Condition>request.path ~ "/statuses/**"</Condition>
            <Name>StatusesRequestPolicy</Name>
        </Step>
    </Request>
    <Response>
        <Step>
            <Condition>(response.status.code = 503) or (response.status.code = 400)</Condition>
            <Name>MaintenancePolicy</Name>
        </Step>
    </Response>
</Flow>
,

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee
X.info

Условия позволяют API-прокси вести себя динамически во время выполнения. Условия определяют операции над переменными, которые оцениваются конвейером обработки Apigee Edge. Условные операторы являются логическими и всегда оцениваются как true или false .

Обзор условий

В этом разделе описывается, как и где использовать условные операторы в Edge. Кроме того, в следующих разделах описывается синтаксис:

Структура условных операторов

Базовая структура условного оператора выглядит следующим образом:

<Condition>variable.name operator "value"</Condition>

Например:

<Condition>request.verb = "GET"</Condition>

Условия можно комбинировать с помощью оператора И, чтобы одновременно применять несколько условий. Например, следующие условия будут true только в том случае, если URI запроса совпадает с /statuses , а HTTP-метод запроса — GET :

<Condition>(proxy.pathsuffix MatchesPath "/statuses") and (request.verb = "GET")</Condition>

Где можно использовать условные операторы

Для управления поведением можно использовать условия в следующих случаях:

исполнение политики

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

В следующем примере выполняется условное преобразование XML в JSON на основе заголовка Accept :

<Step>
  <Condition>request.header.accept = "application/json"</Condition>
  <Name>XMLToJSON</Name>
</Step>

Выполнение потока

С помощью условных операторов можно управлять выполнением именованных потоков в ProxyEndpoints и TargetEndpoints. Обратите внимание, что условному выполнению подлежат только «именованные» потоки. Предварительные и последующие потоки (как запросы, так и ответы) в ProxyEndpoints и TargetEndpoints выполняются для каждой транзакции, обеспечивая, таким образом, безусловную «безопасность от сбоев».

Например, для выполнения условного запроса в зависимости от HTTP-глагола запроса и условного ответа в зависимости от (потенциального) кода состояния HTTP, представляющего ошибку:

<Flow name="GetRequests">
  <Condition>request.verb = "GET"</Condition>
  <Request>
    <Step>
      <Condition>request.path MatchesPath "/statuses/**"</Condition>
      <Name>StatusesRequestPolicy</Name>
    </Step>
  </Request>
  <Response>
    <Step>
      <Condition>(response.status.code = 503) or (response.status.code = 400)</Condition>
      <Name>MaintenancePolicy</Name>
    </Step>
  </Response>
</Flow>

выбор маршрута до конечной точки цели

Используя условные операторы, вы можете управлять целевой конечной точкой, вызываемой конфигурацией прокси-сервера. Правило маршрутизации перенаправляет запрос на конкретную целевую конечную точку. Если доступно более одной целевой конечной точки, правило маршрутизации проверяется на соответствие условию, и если оно истинно, запрос перенаправляется на указанную целевую конечную точку.

Например, для условной маршрутизации сообщений к указанным целевым конечным точкам на основе Content-Type :

<RouteRule name="default">
 <!--this routing executes if the header indicates that this is an XML call. If true, the call is routed to the endpoint XMLTargetEndpoint-->
  <Condition>request.header.Content-Type = "text/xml"</Condition>
  <TargetEndpoint>XmlTargetEndpoint</TargetEndpoint>
</RouteRule>

Дополнительную информацию см. в разделе «Переменные и условия потока» .

Выражения пути

Для сопоставления URI-путей используются выражения пути, где символ "*" обозначает один элемент пути, а символ "**" — несколько уровней URI.

Например:

Шаблон Совпали примеры путей URI.
/*/a/ /x/a/ или /y/a/
/*/a/* /x/a/b или /y/a/foo
/*/a/** /x/a/b/c/d
/*/a/*/feed/ /x/a/b/feed/ или /y/a/foo/feed/
/a/**/feed/** /a/b/feed/rss/1234

Символ % рассматривается как экранирующий символ. Шаблон %{user%} соответствует {user} , но не user .

Переменные

В условных операторах можно использовать как встроенные переменные потока, так и пользовательские переменные. Для получения дополнительной информации см.:

Операторы

При использовании операторов соблюдайте следующие ограничения:

  • Операторы нельзя использовать в качестве имен переменных.
  • Перед и после оператора необходимо поставить пробел.
  • Чтобы включить оператор в переменную, имя переменной должно быть заключено в одинарные кавычки. Например, 'request.header.help!me' .
  • Арифметические операторы ( + * - / % ) не поддерживаются.
  • В Java для операторов используется порядок приоритета .
  • Apigee Edge использует регулярные выражения, реализованные в java.util.regex .

В таблице ниже перечислены поддерживаемые операторы. В выражениях можно использовать символ или слово:

Символ Слово Описание
! Not , not Унарный оператор (принимает один входной сигнал)
= Equals , Is Равно (с учетом регистра)
!= NotEquals , IsNot Не равно (регистр имеет значение)
:= EqualsCaseInsensitive Равно, но регистр нечувствителен.
> или &gt; GreaterThan Больше, чем. Если вы используете > при определении условия в пользовательском интерфейсе Edge, оно преобразуется в >.
>= или &gt;= GreaterThanOrEquals Больше или равно. Если при определении условия в пользовательском интерфейсе Edge используется >=, оно преобразуется в >=.
&lt; LesserThan Меньше, чем. Пользовательский интерфейс Edge не поддерживает символ "<".
&lt;= LesserThanOrEquals Меньше или равно. Пользовательский интерфейс Edge не поддерживает символ <=.
&& And , and И
|| Or Оператор ИЛИ не чувствителен к регистру. Например, OR , Or и or все они допустимы.
() Группирует выражение. Конструктор ( открывает выражение, а скобка ) закрывает его.
~~ JavaRegex

Соответствует регулярному выражению, совместимому с javax.util.regex . Совпадение чувствительно к регистру. Примеры см. в разделе «Сопоставление шаблонов в условных операторах» .

~ Matches , Like Сопоставляет шаблон в стиле glob, используя символ подстановки "*". Сопоставление чувствительно к регистру. Примеры см. в разделе "Сопоставление шаблонов с использованием условий" .
~/ MatchesPath , LikePath Соответствует выражению пути. Сопоставление чувствительно к регистру. Примеры см. в разделе «Сопоставление с шаблонами с использованием условных операторов» .
=| StartsWith Сопоставляет первые символы строки. Сопоставление чувствительно к регистру.

Операнды

Apigee Edge адаптирует операнды к общему типу данных перед их сравнением. Например, если код состояния ответа равен 404, то выражения response.status.code = "400" и response.status.code = 400 будут эквивалентны.

Для числовых операндов тип данных интерпретируется как целое число, если значение не завершается следующим образом:

  • "f" или "F" (например, плавающий элемент, 3.142f, 91.1F)
  • "d" или "D" (удвоить, например, 3.142d, 100.123D)
  • «l» или «L» (длинный, например, 12321421312L)

В этих случаях система выполняет адаптации, показанные в следующей таблице (где RHS обозначает правую сторону уравнения, а LHS — левую):

правая сторона, левая сторона Логический Целое число Длинный Плавать Двойной Нить Сравнимый Объект
Логический Логический Целое число Длинный Плавать Двойной Нить -
Целое число Целое число Целое число Длинный Плавать Двойной Нить Сравнимый -
Длинный Длинный Длинный Длинный Плавать Двойной Нить Сравнимый -
Плавать Плавать Плавать Плавать Плавать Двойной Нить Сравнимый -
Двойной Двойной Двойной Двойной Двойной Двойной Нить Сравнимый -
Нить Нить Нить Нить Нить Нить Нить Сравнимый -
Сравнимый Сравнимый Сравнимый Сравнимый Сравнимый Сравнимый Сравнимый Сравнимый -
Объект - - - - - - - -

Нулевые операнды

В следующей таблице показано, принимают ли условия значение true или false , когда значения в левой (ЛС) и/или правой (ПС) частях указанного операнда равны нулю:

Оператор LHS null Правая часть равна нулю Левая и правая части нулевые
= , == , := ЛОЖЬ ЛОЖЬ истинный
=| ЛОЖЬ ЛОЖЬ ЛОЖЬ
!= истинный истинный ЛОЖЬ
> или &gt; истинный ЛОЖЬ ЛОЖЬ
>= или &gt;= ЛОЖЬ истинный истинный
&lt; истинный ЛОЖЬ ЛОЖЬ
&lt;= истинный ЛОЖЬ истинный
~ ЛОЖЬ Н/Д ЛОЖЬ
~~ ЛОЖЬ Н/Д ЛОЖЬ
!~ истинный ЛОЖЬ ЛОЖЬ
~/ ЛОЖЬ Н/Д ЛОЖЬ

Буквалы

Помимо строковых и числовых литералов, в условных операторах можно использовать следующие литералы:

  • null
  • true
  • false

Например:

  • request.header.host is null
  • flow.cachehit is true

Примеры

<RouteRule name="default">
     <Condition>request.header.content-type = "text/xml"</Condition>
     <TargetEndpoint>XmlTargetEndpoint</TargetEndpoint>
</RouteRule>
<Step>
    <Condition>response.status.code = 503</Condition>
    <Name>MaintenancePolicy</Name>
</Step>
<Flow name="GetRequests">
    <Condition>response.verb="GET"</Condition>
    <Request>
        <Step>
            <Condition>request.path ~ "/statuses/**"</Condition>
            <Name>StatusesRequestPolicy</Name>
        </Step>
    </Request>
    <Response>
        <Step>
            <Condition>(response.status.code = 503) or (response.status.code = 400)</Condition>
            <Name>MaintenancePolicy</Name>
        </Step>
    </Response>
</Flow>