You're viewing **Apigee Edge** documentation.  
[Go to the
**Apigee X** documentation](http://cloud.google.com/apigee/docs/api-platform/fundamentals/understanding-routes). 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.
Watch this video for an introduction to routes, describing the relationship between the
ProxyEndpoint and the TargetEndpoint.
<iframe allowfullscreen frameborder="0" height="315" src="https://www.youtube.com/embed/Lg3C-CPYcIo" width="560"></iframe>

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

![](https://docs.apigee.com/static/api-platform/images/ApigeeProxyRoute_v2.png)

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)](https://docs.apigee.com/api-platform/fundamentals/virtual-hosts).
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.

**Video:** Watch a short video to learn more about API proxy endpoints.
<iframe allowfullscreen frameborder="0" height="480" src="https://www.youtube.com/embed/tjpqYUbhPec" width="560"></iframe>

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

**Video:** Watch a short video to learn more about target endpoints.
<iframe allowfullscreen frameborder="0" height="480" src="https://www.youtube.com/embed/ITPOsjZGVfc" width="560"></iframe>

### 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](https://docs.apigee.com/api-platform/reference/api-proxy-configuration-reference#proxyendpoint-conditionalroutes)
and [Conditions reference](https://docs.apigee.com/api-platform/reference/conditions-reference).

> [!NOTE]
> **Note:** **Order is important**: If you have more than one RouteRule in a ProxyEndpoint, their order in the XML configuration is important. The first RouteRule to "match" gets executed. (RouteRules with no condition always match.) In the previous example, if the unconditional "default" RouteRule came first, it would be executed even if the condition of the "MyRoute" rule would have matched. So list your conditional RouteRules before an unconditional RouteRule.

**Video:** Watch a short video to learn how to route to a target endpoint using
conditional targets.
<iframe allowfullscreen frameborder="0" height="480" src="https://www.youtube.com/embed/URxpF9iWRaA" width="560"></iframe>

### 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](https://docs.apigee.com/api-platform/fundamentals/virtual-hosts)
- [API proxy configuration reference](https://docs.apigee.com/api-platform/reference/api-proxy-configuration-reference)
- [Endpoint properties reference](https://docs.apigee.com/api-platform/reference/endpoint-properties-reference)
- [Load balancing
  across backend servers](https://docs.apigee.com/api-platform/deploy/load-balancing-across-backend-servers)