This pageapplies toApigee andApigee hybrid.

View Apigee Edge documentation.

Conditions enable API proxies to behave dynamically at runtime. Conditions define operations on variables, which are evaluated by the Apigee processing pipeline. Conditional statements are boolean and always evaluate totrue orfalse.

Conditions overview

This section describes how and where to use conditional statements with Apigee. In addition, the following sections describe the syntax:

• Operators
• Operands
• Literals

Structure of conditional statements

The basic structure of a conditional statement is:

<Condition>variable.nameoperator"value"</Condition>

For example:

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

You can combine conditions withAND to enforce more than one at a time. For example, the following conditions evaluate totrue only if the URI of the request matches/statusesand the HTTP verb of the request isGET:

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

Where you can use conditional statements

You can use conditions to control behavior in the following:

• Policy execution
• Flow execution
• Target endpoint route selection

Policy execution

Using conditional statements, you can control the enforcement of policies. A common use case is conditional transformation of response messages, based on HTTP header or message content.

The following example conditionally transforms XML to JSON based on theAccept header:

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

Flow execution

Using conditional statements, you can control the execution of named flows in ProxyEndpoints andTargetEndpoints. Note that onlynamed flows can be executed conditionally. Preflows and postflows (both request and response) onProxyEndpoints andTargetEndpoints execute for every transaction, and thus provide unconditionalfailsafe capabilities.

For example, to execute a conditional request flow based on the HTTP verb of the request message, and conditional response flow based on a (potential) HTTP status code representing an error:

<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>

Target endpoint route selection

Using conditional statements, you can control the target endpoint invoked by proxy endpoint configuration. A route rule forwards a request to a particular target endpoint. When more than one target endpoint is available, the route rule is evaluated for its condition and, if true, the request is forwarded to the named target endpoint.

For example, to conditionally route messages to designated target endpoints based onContent-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>

SeeFlow variables and conditions for more information.

Path expressions

Path expressions are used for matching URI paths, using* to represent a single path element and** to represent multiple URI levels. Curly braces{name} can also be used to match a single path element and provide clarity to the reader. The variablename is only only used for clarity and does not populate the matched value in a flow variable.

For example:

% is treated as an escape character. The pattern %{user%} matches{user} but notuser.

Variables

You can use both built-in flow variables and custom variables in conditional statements. For more information, see:

• Flow variables reference: A complete list of the built-in variables
• ExtractVariables policy: Instructions on setting custom variables

Operators

When using operators, observe the following restrictions:

• Operators cannot be used as variable names.
• A space character is required before and after an operator.
• To include an operator in a variable, a variable name must be enclosed in single quotes. For example,'request.header.help!me'.
• Arithmetic operators (+ * - / %) are not supported.
• Java precedence is used for operators.
• Apigee relies on regular expressions as implemented injava.util.regex.

The following table lists the supported operators. You can use the symbol or the word in yourexpressions:

Operands

Apigee adapts operands to a common data type before comparing them. For example, if the response status code is404, the expressionresponse.status.code = "400" and theresponse.status.code = 400 are equivalent.

For numeric operands, the data type is interpreted as integer unless the value is terminated as follows:

• f orF (float, for example,3.142f, 91.1F)
• d orD (double, for example,3.142d, 100.123D)
• l orL (long, for example,12321421312L)

In these cases, the system performs adaptations shown in the following table (where RHS refers to the right side of the equation and LHS is the left side):

<RouteRulename="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>