Multiple revision usage

pratysin
Participant IV

Hi Team,

I have a scenario where i have 2 customers A and B, using an API Proxy name : "HelloWorld". I have total 5 revision of the above proxy.

Now customer A wants to use revision 4 and customer B wants to use revision 5. Is it possible in APIGEE?

Thanks in advance.

Regards

Pratyush

Solved Solved
0 4 213
1 ACCEPTED SOLUTION

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.

View solution in original post

4 REPLIES 4

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.

Thanks alot @Dino


I think now i am clear with all details but what if the same query in relation to versions means my question will change as :

I have a scenario where i have 2 customers A and B, using an API Proxy name : "HelloWorld". I have total 5 VERSIONs of the above proxy.

Now customer A wants to use version 4 and customer B wants to use version 5. Is it possible in APIGEE?

Please confirm if its possible. Many thanks again.

Regards

Pratyush

If you use the term VERSION and not revision, then the answer is a little different. But the problem remains the same.

A "revision" is a specific term for a thing in Apigee. And as I said you can deploy at most one revision of an API Proxy to an environment, at a time. You can have revision 4 OR revision 5 deployed, but not both.

What I just wrote is not strictly true. the actual limitation is that for each deployed proxy, the combination of {vhost, basepath} must be unique. a proxy listens on a particular vhost (configured by name in Apigee) and a basepath for the proxyendpoint. Suppose the basepath is /foo. You can have at most one API proxy listening on the vhost named "secure", and listening on basepath /foo. If you have proxy1 which listens on /foo and proxy2 that also listens on /foo, then you can deploy at most one of them.

If you have mutliple revisions of proxy1 , and they all have /foo as the basepath, then you can deploy at most one revision of that proxy.

If you divert from the customary practice and change the basepath between revisions of your proxy, then it will be possible for you to deploy multiple revisions of the same proxy at the same time. For example if revision 1 of proxy1 has basepath of /foo and revision 2 of proxy1 has basepath of /bar , then there is no conflict and you can deploy both revision 1 and revision 2 at the same time.

If you change your term to VERSION, then ... that changes things a bit. I can have a proxy named "HelloWorld_v4" and another proxy named "HelloWorld_v5" and they are different proxies. Each with their own revisions. And it will be possible to deploy both HelloWorld_v4 and HelloWorld_v5 to the same environment (and vhost) at the same time.

However, you still must respect the requirement that the combination of {vhost, basepath} must be unique for all deployed proxies.

The better way to get customer-dependent interface versioning is to design it into the proxyendpoint itself. Make the proxyendpoint be smart about which "version" of the interface it is offering, and where to get other versions.

For example, the logic might be

  1. proxy1 receives request on /foo/yam
  2. proxy1 validates credentials, finds API Product with custom attr indicating the client wants version 4 of the interface
  3. proxy1 is currently serving version 5 of the interface. So proxy1, Using RouteRules and Condition elements, "proxies" to a different API proxy that swerves version 4 of the interface.

Not applicable

I found a way to deploy two different revisions of a proxy in the same environment. If you have two different virtual hosts, then deploy revision 4 with modifying one virtual host in proxy endpoint and revision 5 with other virtual host. I tested this works as expected.