Redirection to different backend endpoints (on different hosts) based on URI parameters

[#1]

I want to ask if I could configure a proxy that would redirect my incoming requests to different backend endpoints based on query param or the URL.

e.g. I have multiple customers for which I create a different instance of application in the cloud. Each instance is hosted on a separate machine with a different IP. The clients of my application would access the URL of proxy configured in Apigee and Apigee should redirect that call to appropriate instance of application. e.g. client A for application instance A would access the proxy and proxy should be able to redirect that request to application instance A. The client A might supply some parameter in the query string that would identify that the request should be routed to application instance A. Is this possible?

[DChiesa]

yes, that is possible. in fact, what you describe is a quite mainstream and common use-case for Apigee Edge among the customers I know of. I wouldn't use the term "redirection" though. I think you mean "proxy" when you say "redirect". Redirect is something an HTTP Server does to direct a client to a different address, then the client contacts that backend server directly. The best way to use Apigee Edge is not as a redirector, but as a proxy. So Apigee Edge would *proxy* the client call to a different backend.

--

Apigee Edge acts as a smart, configurable proxy. An API Proxy running in Apigee Edge can authenticate the credentials on Inbound requests - like an API Key, or an OAuth Token, or something else.

After successful authentication, the proxy will have access to information about the client, that you (the API Program manager) have associated to the client in the Apigee Edge store. This information might include:

• the agreed-upon level of service for the client. Maybe they can make 1000 calls per hour?
• preferences for the client. Maybe the client app needs only a subset of the information returned by the API.
• backend target URL for the client
• other things

The smart proxy can then make decisions about what to do with the authenticated request, given all that information. It could route to the specified backend. It could Route to the specified backend, and then filter or shape the response. It could enforce a quota.... Lots of options here.

Custom Attributes Make this Possible

The key to this is the custom attributes feature in Apigee Edge. Each client app registered in Apigee Edge gets credentials - this is an API Key (or consumer key) and a consumer secret. You can optionally associate a set of data, in key/value pair form, to each client app in Apigee Edge.

It does not matter which form of client app authentication you use. For app authentication, you can choose :

• simple api key authentication, in which case the client app presents the key with each request. The proxy authenticates the key. The secret is not used.
• OAuth token authentication, in which case the client app presents a short-lived token with each inbound request. The app first needs to obtain a token by presenting the consumer key (api key) and secret to the token dispensing endpoint. Then for every other request, it just presents the returned token, and the smart proxy authenticates that token.
• Some other mechanism. Some people use HTTP Signature, JWT, or other approaches.

In all cases, after authentication, the smart proxy has access to the client id (also known as the "API Key", sometimes called the "consumer key", other times called the "consumer id" - these are all the same thing!). And the smart proxy also has access to any custom attributes stored with the client entity.

Then the smart proxy can route the request to an endpoint stored on the custom attributes.

Super easy. You can look at this Q&A for some further information on the technique.