Solved: API versioning within an Apigee environment to sup... - Page 2

nmunro · 06-23-2015 03:00 AM

Hello Community,

I am looking for some feedback and best practice direction on an approach to API versions within a single Edge environment.

We would like to follow a process for release to production that mirrors what we do in areas other than API development.

The process is very simple and nothing out of the ordinary:

We have 3 environments: prod, qas, and dev.
When the development passes tests by the developer it is moved to the test environment
Once in "test" it is tested further by the users/customers
When it is deemed ready it is then moved to production

We have been discussing how to keep a stable version in the test environment that matches what we have in prod. This is what we'd have visible as a test environment via the dev portal for app developers.

To keep to our process above we would then have another version in the test environment for API versions that need to be tested but are not ready for production.

So, we were thinking of something like:

https://basepath/api1/v1/resource (prod)
https://basepath/api1/v1/resource?test=true (qas, but matches prod and would change only with new version to prod. This is test version visible on dev portal)
https://basepath/qas/api1/v1/resource (qas, new api revision or version under test but not ready for prod)

Is this an approach we should follow or is there a better or simpler way to do this?

What is the most common approach to what app developers use via the dev portal as a sandbox or test environment?

Thanks

Neil

gnanasekaran

Hi Neil,

Adding to maruti's comments, you typically do not need to create different resource paths for different env, this makes your API inconsistent across env and becomes difficult to test and consume.

Better way to handle this is Virtual Host and Host Aliases, for eg, typically you would have configued 3 different domain names for each of your env,

dev-api.me.com -> dev env

qa-api.me.com -> qa env

api.me.com -> production

all have same set of resource, just different hostname. Its pretty straightforward to setup and many of our customers follow this approach

This way you could map your existing development lifecycle / continous delivery to map to Apigee's environment

"We have been discussing how to keep a stable version in the test environment that matches what we have in prod. This is what we'd have visible as a test environment via the dev portal for app developers." -- Sounds like you need another env, probably 'stage' or 'sandbox' before it goes to production.

In Apigee, Environments are logical, so its easier to setup a new environment without need for additional infrastructure. Plus, it also provides a cleaner way to manage your delivery process.

Thanks,

View solution in original post

API versioning within an Apigee environment to support APIs visible on the developer portal