The short answer is yes.
In general, an Apigee API proxy can route to different targets based on dynamic evaluation of criteria that you specify. The criteria or conditions can examine:
- information directly related to the request. Such as: request headers, request payload, URL path, verb, originating client IP address
- information indirectly related to the inbound request. such as: the name of the proxy handling the inbound request, client ID (derived from an OAuth token), the DN or SAN on the client certificate if you are using 2-way TLS, some custom attribute on the app, developer, or API product (again derived from the OAuth token).
- environmental information, such as: time of day, name of the Apigee environment or organization.
- or data that derives from the inbound request and some other external data. For example, your proxy can "look up" a route destination based on client ID or some other request element. Imagine an externally-hosted routing table; Apigee can route to different targets based on a lookup in that dynamic table
In summary: you can configure Apigee to route requests based on all sorts of things. How does it work? There are two different approaches.
- Define a static set of targets in the API proxy bundle. In Apigee these things are represented as "TargetEndpoints", and each one might have a single server, or a set of server endpoints (Apigee does load balancing and health monitoring across the set). Then, apply conditions in the ProxyEndpoint to select a single TargetEndpoint. You can do this with RouteRules in Apigee.
- Define a single target in the API proxy bundle. Then, apply your conditional logic in the Target flow to set the target.url variable to the appropriate value. This is fully dynamic, which is nice. The downside is, you don't get the load balancing and health monitoring across the set of all possible server endpoints in this case.
You might want to read up on RouteRules if you're not familiar with the possibilities there. OK, now to your specific questions. In both cases you said
in comparison with predefined json array of values that need to be stored& pulled from kvm
Getting data from the KVM is no problem. I assume you have a good idea for how to do that, and how to format the data. You'll want to cache the data of course, so set the TimeToLive value in the KVM Get policy appropriately. That saves I/O when the proxy operates at scale.
In the first case you said you want to evaluate "header1" and "header2" and then combine that with the routing table obtained from the KVM, to make a routing decision. Depending on how complex the logic is, you may want to rely on JavaScript to encode it. For example, you could do something like this:
var h1 = context.getVariable('request.header.header1');
var h2 = context.getVariable('request.header.header2');
var routingTable = JSON.parse(context.getVariable('thing-retrieved-from-KVM'));
var selected = routingTable[h1] && routingTable[h1][h2];
if (selected) {
context.setVariable('selected-route', selected);
}
else {
context.setVariable('selected-route', 'default');
}
And then set target.url to the appropriate URL for that selected route.
The second case is essentially the same, except you're retrieving data from the request payload. It works basically the same way.
There are lots of other variations possible. Obviously you might have different things in your routing table, so you might need to use different JavaScript to perform the lookups. This is just a simple example, something to start with.
Some time ago I produced an example of dynamic selection of a target URL based on a weighted random approach. That is similar to what you describe here, but slightly different. It may be helpful to you: https://github.com/DinoChiesa/ApigeeEdge-BlueGreen-1
LinkedIn
Twitter
