Understanding routes

You're viewing Apigee Edge documentation.
Go to the Apigee X documentation. info

A route determines the path of a request from the ProxyEndpoint to the TargetEndpoint. Included in the route is the URL used to access the API ProxyEndpoint and the URL of the backend service defined by the TargetEndpoint.

Determining the URL of the API proxy endpoint

The following image shows a request coming in to the ProxyEndpoint from an app, and that request being directed to the backend service:

After you create an API proxy on Edge, the default URL that an app uses to access the proxy has the form:

http://{org-name}-{env-name}.apigee.net/{base-path}/{resource-path}

https://{org-name}-{env-name}.apigee.net/{base-path}/{resource-path}

where:

• {org-name} is your organization name. This name is created when you create an account on Edge.
• {env-name} is the Edge environment name. By default, all Apigee organizations created in the cloud are provisioned with two environments: 'test' and 'prod'. When deploying an API proxy, you can choose to deploy it to one or both environments.
• {base-path} and {resource-path} are defined when you create the API proxy.

When a request comes in to Edge, Edge parses the URL to direct the request to the correct ProxyEndpoint. For example, the following URL is used to access an API proxy on Edge:

http://myOrg-prod.apigee.net/v1/weather/forecastrss

If you examine the ProxyEndpoint definition for the API proxy in the figure above, you can see how this URL is parsed by Edge:

1. The domain portion of the URL, http://myOrg-prod.apigee.net, corresponds to a virtual host on Edge. In the ProxyEndpoint definition above, the API proxy uses the <VirtualHost> tag to reference a virtual host named default. You can have multiple virtual hosts defined in your environment.
   
   A virtual host defines the domains and ports on which an API proxy is exposed. A virtual host also defines whether the API proxy is accessed by using the HTTP protocol, or by the encrypted HTTPS protocol. For detailed information on virtual hosts, see About virtual hosts (Beta).
2. The second part of the URL, /v1/weather, is determined by the <BasePath> element in the ProxyEndpoint. The base path must be unique to the API proxy for the environment so that two API proxies do not have the same base path.
3. The third part of the URL, /forecastrss, is a resource defined by the API proxy with the corresponding Conditional Flow defined by the <Flows> tag.

Determining the URL of the target endpoint

The <RouteRule> tag in a ProxyEndpoint definition determines the target of the API proxy, and is evaluated after all policies in the PreFlow, Conditional Flows, and PostFlow of the ProxyEndpoint request are processed.

A ProxyEndpoint can define the target as:

• A direct URL to a backend service.
• A single TargetEndpoint definition.
• Multiple TargetEndpoints where the API proxy delegates the request to a target endpoint based on a condition.
• Null route or target, meaning the request is not forwarded to a target. Instead, all of the processing of the request, and the generation of the response, occurs on Edge.

Direct URL

A ProxyEndpoint can directly invoke a backend service, bypassing any named TargetEndpoint configuration. For example, the following <RouteRule> always makes an HTTP call to http://api.mycompany.com/myAPI:

<RouteRule name="default">
  <URL>http://api.mycompany.com/myAPI</URL> 
</RouteRule>

However, because there is no TargetEndpoint, you can only add policies to the flows defined by the ProxyEndpoint.

Single target

In a single target definition, the ProxyEndpoint references a single TargetEndpoint definition by name, as shown in the figure above:

<RouteRule name="default">
  <TargetEndpoint>default</TargetEndpoint>
</RouteRule>

All requests to this API proxy are directed to the same TargetEndpoint definition. The <URL> tag in the TargetEndpoint determines the location of the backend service. in the figure above, the target URL is http://weather.yahooapis.com.

Conditional targets

The <RouteRule> tag lets you direct a request to a target based on a condition. You can use flow variables, query parameters, HTTP headers, message content, or contextual information such time of day and locale to determine the target endpoint. For example, you might include a geographical area, such as US and UK, in a request URL. You can then route a request to a target endpoint based on the region.

The following route rule evaluates an HTTP header in a request. If the HTTP header routeTo has the value TargetEndpoint1, then the request is forwarded to the TargetEndpoint named TargetEndpoint1. If not, then the request is forwarded to TargetEndpoint2.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
 <TargetEndpoint>TargetEndpoint2</TargetEndpoint>
</RouteRule>

If you have multiple route rules, create one as the 'default', that is, as a route rule with no condition. Ensure that the default route rule is defined last in the list of conditional Routes because rules are evaluated top-down in the ProxyEndpoint.

See also Conditional routes and Conditions reference.

Null route

A null route supports scenarios in which the request message does not need to be forwarded to a TargetEndpoint. This is useful when the ProxyEndpoint performs all of the necessary processing, for example by using JavaScript to call an external service.

The following example defines a null route:

<RouteRule name="GoNowhere"/>

Learn more

• About virtual hosts
• API proxy configuration reference
• Endpoint properties reference
• Load balancing across backend servers