Hi, John.
Seems virtualHost + BasePath must be unique!
Correct. Apigee Edge uses the VirtualHost concept, and in Apigee Edge, the combination of vhost+basepath must be unique across all deployed proxy revisions. There is no way to change that behavior.
I am not clear on exactly the reqiurement here, because we've resuscitated a thread from nearly 2 years ago. But I think you want to route requests to multiple different proxies. In Apigee Edge, the easiest way to route inbound requests to different proxies is to use the left-most path segment as the discriminator. The basepath that you use in a proxyendpoint specifies the leftmost path segment for requests that the proxy will handle. So supposing you have these proxies
| proxy name |
basepath |
| proxy1 |
/p1 |
| proxy2 |
/p2 |
| proxy3 |
/p3 |
| |
|
..then , for an inbound request to https://myhost/p1 gets routed to proxy1, and https://myhost/p2 gets routed to proxy2.
Another way you can discriminate inbound requests in Apigee Edge is using the hostname. If you create multiple different VirtualHosts with distinct host names , and deploy proxy1 to vhost1, and proxy2 to vhost2, then you can do something like this:
If you don't like either of those options, because for some reason you don't want to use the leftmost pathsegment and you ALSO don't want to use the hostname as a discriminator, then you need to do something else to be able to "route" inbound requests to different proxies. The options as I see them are:
- use an external WAF or load balancer or url rewriter to do that. OR
- build what we are calling a "front door" proxy that does the rewriting.
It's the same approach, it's just that in the latter case you are using Apigee itself as the router/load-balancer.
In either case, you're just building a layer on top of the request routing facility that exists in Apigee Edge. The only benefit is, the hostname or leftmost path segment isn't exposed to external callers or clients. But Edge will still use the combination of hostname+pathprefix as the way to route requests to distinct proxies, so your "rewriter" is just "hiding" that.
What I mean by "hiding" - an inbound request might include a "X-DESIRED-TARGET" header, and the WAF or "front door" could examine that, and then rewrite the inbound request accordingly, with a unique host+pathprefix, so that Edge can do its thing.
If you use the "front door" proxy, it needs access to "the map". The rules that say "this request goes to proxy1, this other request goes to proxy2, etc." It would be up to you to define that map, and what the discriminator is. You could use, as a discriminator, a specially defined header, or the leftmost segment in the path, or a queryparam, or a form parameter, OR something else in the request. (For now we are assuming all inbound requests use the same hostname).
THEN, in the front-door proxy you can use the "chained proxy" feature as described in Anil's video, but you will need to use a Path:
<LocalTargetConnection>
<Path>{this-is-a-message-template}</Path>
</LocalTargetConnection>
...and the value of variable that holds the path will be determined by the application of your url mapping logic. Maybe in JavaScript.
Does this help?
LinkedIn
Twitter
