A way for managing your API versions with Azure
Tags: azure, management, webdev, routing
Published: 2020-04-15 15:55:53

Hi guys,

I've recently been playing for a personal project with [__Azure Front Door__][Azure Front Door Docs] service and found a utility that would be great in my opinion. For those of you that don't know what is [__Azure Front Door__][Azure Front Door Docs] service let me say that allows you to define, manage, and monitor your global routing for your web traffic by optimizing for best performance and instant global failover for high availability. This is the first sentence that appears in the [_documentation_][Azure Front Door Docs] but you have many more functionalities like URL-based routing, URL redirection, URL rewriting, Multiple-site hosting, Session affinity, Custom domains, etc.

## You have an API app

So, _I want to expose how to maintain and evolve your API app_ providing access to different versions using Azure Front Door service. I assume __you have an API app__ that is working properly fine and granting services to users worldwide and your host is in Azure or any other web hosting provider, doesn't matter at this point. Now, __you want to add some more functionalities__ and some of your methods will change completely the response. This could be seen as a __major change__ and implies a version change so how will you manage this new version to your whole community of users?

In this case, the best approach should be to maintain the two different versions and recommend to your users to, proactively and progressively, modify their applications to the new API version.

## But, how will you deploy your changes to the internet? 

If you modify your current API app, you will have to plan a shutdown time -seconds, minutes, hours or any other kind of time depending on your changes and your deployment way- and inform your users about it.

Another approach could be to deploy your new version as a new app in your hoster. This implies a different URL from the current app making your users be confused and increase the difficulty to modify their apps to the new version.

As we see, there isn't a completely good solution that covers everything. So, Azure Front Door service comes here to resolve our problems.

## Configuring Front Door for URL routing

[__Azure Front Door__][Azure Front Door Docs] provides us with the power of __URL-based routing__. This means that you can route your traffic based on patterns to different pools. In the case of your API app, __we will consider that you deployed the new version as a different API app__ to avoid any disturbance for your users so you have two different pools, __version 1 and version 2 API apps__. It seems that now we are able to keep a _unique domain_ and, depending on the URL parameters, use one or another app.

By default, [__Azure Front Door__][Azure Front Door Docs] provides you with this URL so _you don't have to worry about it_ although you want to use your own domain. Please, follow this [article][Azure Front Door Custom Domain Docs] in order to configure your own domain.

Our pattern strategy to define our API versions will be configured in Azure Front Door, so we have to decide how we want to serve our methods. A common pattern nowadays is to add the version number in the URL like:

```
https://api.domain.com/v1.0/api-method
```

And that's how you will configure your routing rules. Let's take a look at the following screenshot with the most relevant parameters to configure. The first one allows us to set the __URL pattern__ where we describe our version 1 API app calls. We must avoid the protocol and domain name of the URL and set the query like the following `/api/v1.0/*`. 

![Azure Front Door rule configuration](https://dev-to-uploads.s3.amazonaws.com/i/q0q3iutsfbj07fi3fsq3.png)

The following parameter is the _route type_ which defines how to __process the request__, in our case, you must select _Forward_ and the proper _Backend Pool_. The third one I want to show you is _"Custom forwarding path"_ parameter where we should __type the URL of our API app__ to match with. If we open the API app for notifications functionality we should write here the relative URL to the notifications methods, `/api/notifications/` as an example.

```
/api/v1.0/messages -> /api/notifications/messages
/api/v1.0/messages?$select(title,desc) -> /api/notifications/messages?$select(title,desc)
```

This is all the stuff you need to configure the service to provide with URL-based routing functionality. Moving forward, you are able to configure new versions of your API adding more and more rules and disabling or removing those that you don't need anymore. 

Managing versions of your API app enabling or disabling routing rules is easier than starting or stopping API apps in different web hosting platforms or doing lines of code that reads an URL parameter and decides which response to send. 

> _Consider this as a "Single Responsibility" pattern of **SOLID** principles where you have two clearly separated layers one for version management and the other for providing the proper functionality._

## What else can do

As I said at the beginning of this article, [__Azure Front Door__][Azure Front Door Docs] service provides lots of different functionalities you can take advantage of. If you want to evolve from here you can deploy your API app at several data centers and provide Geo-affinity and load balancing you your users depending on their localizations.

The following list provides you with links to the official documentation and I expose in this article:

* [Azure Front Door Docs]
* [Azure Front Door Custom Domain Docs]
* [Azure Front Door Routing Methods]
* [Azure Front Door Routing Architecture]

Hope you enjoyed reading this article. Please, leave any comment to help me and the community if you want to share something.

[Azure Front Door Docs]: https://docs.microsoft.com/en-us/azure/frontdoor/front-door-overview
[Azure Front Door Custom Domain Docs]: https://docs.microsoft.com/en-us/azure/frontdoor/front-door-custom-domain
[Azure Front Door Routing Methods]: https://docs.microsoft.com/en-us/azure/frontdoor/front-door-routing-methods
[Azure Front Door Routing Architecture]: https://docs.microsoft.com/en-us/azure/frontdoor/front-door-routing-architecture