CODEWITHSUNDEEP
apiproductazure-api-managementenvironments
Roberto Rodríguez
Roberto Rodríguez

Reputation: 35

Different backend endpoints in APIs depending on Products in Azure API Management

I'm an absolute newbie in Azure API Management and I have a doubt regarding how to manage Products and APIs.

Let's imagine this scenario: I create 3 diferent Products: One for representing my Development environment (DEV), the second one for representing my Preproduction environment (PRE) and the last one to represent my Production environment (PRO). I create several APIs which I want to publish in my DEV environment and later promotion to the others. So I need every API in every different Product to point a different backend service, as my backend services are different in every environment.

In example: I have 3 different versions of my backend service: ServiceDEV, ServicePRE and ServicePRO. As I develop my API, I use as backend service the one named ServiceDEV, and so my API is assigned to the Product DEV. Later I want to keep this DEV version for my API but I also want to "deploy" that API in the Product PRE to make it act as a façade for ServicePRE, and the same would happen when promotioning it to PRO.

The problem with this approach is that I need to clone the APIs and change their settings to make them point to the correct backend endpoint every time I want to promotion one of them from one environment to another, thus losing all the versioning for that API, as the cloning operation just clones the current version of the API.

I don't know if policies would meet my needs in this subject.

I hope you get what I'm trying to mean...

How can I manage this situation? Am I focusing this subject in a wrong way? Any idea about how to overcome this?

Thank you!

Upvotes: 1

Views: 1660

Answers (1)

Vitaliy Kurokhtin
Vitaliy Kurokhtin

Reputation: 7840

If you follow this approach then you indeed could use policies to manage different backends for different products. You could create APIs without specifying backends ervice URL entirely and later use set-backend-service policy at product level to direct call to a proper endpoint. One limiting factor of this approach is that whatever changes you may want to do to an API in dev environment (think change signature of an operation, or policy) will be immediately visible in other environments as well as this is a single API in all of them. If this is an issue, then consider having duplicate (triplicate) APIs - one per environment and later move their configuration via Azure API call.

Upvotes: 1

Related Questions