It is valid and possible to deploy At most one revision of a proxy in a given apigee environment. As a result, it is not possible to deploy both r4 and r5 in the same environment.
You could deploy r4 in one environment (eg, test), and r5 in another environment (eg, dev). That would be perfectly legal and valid and people do this all the time. But those revisions would listen on different virtual hosts.
You would then have to direct customer A to use the vhost for env1, and customer B to use the vhost for env2. This would work, technically, but there are downsides.
- usually people have a single production environment for live proxies. Having a distinct environment and vhost for different customers isn't a scalable approach to the problem. What happens if you have customer 3 who wants revision 6?
- What do you do when you have proxy2, with its own set of revisions, and different customers want different revisions of tHAT ? What if each customer has more than one client app? A web app, a mobile app, a Point-of-sale app. Now you have a combinatoric explosion of revisions, environments, customers, and clients. It's not solvable this way.
What is the real requirement? "customer A wants revision 4 and customer B wants revision 5" isn"t quite clear, I think. There is something about "revision 4" and "Revision 5" that the respective customers want. Maybe it's the authentication, maybe it's the shape of the response payload, or something else.
You can accomplish what you want - a configurable experience for different customers, different clients - using Apigee API Products and custom attributes.
You can define distinct API Products (product A and product B) that wrap up API Proxies, and then attach attributes to the products. Create credentials for the respective products and give them to the customers. Now customer A has credentials for Product A, and customer B has credentials for product B.
In the API Proxy, verify the credentials (verifyAPIKey or VerifyAccessToken). This implicitly retrieves the custom attributes on the product for which the credential is authorized. Now, in the API proxy, examine the custom attributes and using Condition elements within you proxy, modify the behavior of the proxy (authentication, response shaping, or whatever) according to the value of the custom attributes.
You may also want to take advantage of multiple proxyendpoints in a API proxy bundle. For example you could have a proxy endpoint that listens at a basepath of /r4/foo and another that listens at /r5/foo. And you can use that basepath to allow clients to distinguish which version of the proxy they want. Deploy one API Proxy with 2 proxy endpoints. This also doesn't scale well beyond 2 revisions or so, but it may get you out of your current predicament.
LinkedIn
Twitter
