API Connect

Hi All,

We are developing public APIs which has multiple versions and each version has its own subscribers, We are analyzing the best recommended approach for developing such APIs, Below are possible 2 approaches and we are in the process of picking 1 which is recommended.

For the argument sake lets assume we have a booking API and it has 2 versions and each version has its own subscribers.

Approach 1. 

• Create 2 products "booking_1.0.0" and "booking_2.0.0" and associated APIs "booking_api_1.0.0" and "booking_api_2.0.0" under the same booking folder with 1.0.0 and 2.0.0 as subfolder sharing the same service register file.
• Deploy 1.0.0 API first and it will be shown in published state, Later Deploy 2.0.0 API , As the product name is same only version is changing while deploying 2.0.0 API, 1.0.0 product will goes to deprecated state and 2.0.0 product will be shown in Published state.
• This way both APIs are accessible from their respective subscribes.

Approach 2.

• Create 1 product "booking_1.0.0" associating with 2 APIs "booking_api_1.0.0" and "booking_api_2.0.0" which will be placed under the folder booking with subfolder 1.0.0 and the same service register file mentioning about both APIs in an array.
• When we deploy, Both APIs will be deployed together and they will be sharing the single product.
• However in this scenario in future if we do any enhancement for v2 and deploy, Along with v2, v1 API will also gets deployed without any changes and if there is any downtime for the product both APIs will be unavailable.

I'd recommend approach 1, thats making proper use of the API Product lifecycle in API Connect.

It is worth saying that there is no automatic deprecation just because the product names are the same - there is no magic automatic behaviour there since that might not be what everyone wants. When you publish 2.0.0 you can select to "Replace" the original product which will immediately remove 1.0.0 and move all subscribers to 2.0.0, or you can select to "Supersede" the original one which will deprecate the APIs within it and allow the subscribers to migrate over at their own pace. Both versions of the API would stay functional.

Your second approach basically dooms you to having 2 APIs forever since you will be unlikely to ever move all subscribers over from 1.0 to 2.0 if theyre both within the same product. Essentially thats just doubling the work as you have two completely independent APIs and no real versioning at all.

Cheers,

Chris

Hi All,

We are developing public APIs which has multiple versions and each version has its own subscribers, We are analyzing the best recommended approach for developing such APIs, Below are possible 2 approaches and we are in the process of picking 1 which is recommended.

For the argument sake lets assume we have a booking API and it has 2 versions and each version has its own subscribers.

Approach 1. 

• Create 2 products "booking_1.0.0" and "booking_2.0.0" and associated APIs "booking_api_1.0.0" and "booking_api_2.0.0" under the same booking folder with 1.0.0 and 2.0.0 as subfolder sharing the same service register file.
• Deploy 1.0.0 API first and it will be shown in published state, Later Deploy 2.0.0 API , As the product name is same only version is changing while deploying 2.0.0 API, 1.0.0 product will goes to deprecated state and 2.0.0 product will be shown in Published state.
• This way both APIs are accessible from their respective subscribes.

Approach 2.

• Create 1 product "booking_1.0.0" associating with 2 APIs "booking_api_1.0.0" and "booking_api_2.0.0" which will be placed under the folder booking with subfolder 1.0.0 and the same service register file mentioning about both APIs in an array.
• When we deploy, Both APIs will be deployed together and they will be sharing the single product.
• However in this scenario in future if we do any enhancement for v2 and deploy, Along with v2, v1 API will also gets deployed without any changes and if there is any downtime for the product both APIs will be unavailable.

Hi All,

We are developing public APIs which has multiple versions and each version has its own subscribers, We are analyzing the best recommended approach for developing such APIs, Below are possible 2 approaches and we are in the process of picking 1 which is recommended.

For the argument sake lets assume we have a booking API and it has 2 versions and each version has its own subscribers.

Approach 1. 

• Create 2 products "booking_1.0.0" and "booking_2.0.0" and associated APIs "booking_api_1.0.0" and "booking_api_2.0.0" under the same booking folder with 1.0.0 and 2.0.0 as subfolder sharing the same service register file.
• Deploy 1.0.0 API first and it will be shown in published state, Later Deploy 2.0.0 API , As the product name is same only version is changing while deploying 2.0.0 API, 1.0.0 product will goes to deprecated state and 2.0.0 product will be shown in Published state.
• This way both APIs are accessible from their respective subscribes.

Approach 2.

• Create 1 product "booking_1.0.0" associating with 2 APIs "booking_api_1.0.0" and "booking_api_2.0.0" which will be placed under the folder booking with subfolder 1.0.0 and the same service register file mentioning about both APIs in an array.
• When we deploy, Both APIs will be deployed together and they will be sharing the single product.
• However in this scenario in future if we do any enhancement for v2 and deploy, Along with v2, v1 API will also gets deployed without any changes and if there is any downtime for the product both APIs will be unavailable.