Azure APIs = Digital Legos

As was mentioned in the previous post, I had to modify my Azure series because of the exciting new announcements that were made in the past few months. For those of us who see the perks and power behind platform as a service (PaaS), there is definitely a lot to be happy about. Prior to this point, there were really only two options available for platform as a service... Websites and Mobile Services.

Don't get me wrong, both are powerful, but recently Microsoft opened up the options available with the new offerings available. The first being WebApps, which I've previously done several posts on Azure websites, and there is absolutely no differences between websites and web apps. Just a rebranding to try and show how these can coexist to make a better cloud solution.

The next one, and the focus of this post, is Azure API Apps. Which Microsoft is pushing as the best possible option for providing and building APIs. The idea being that is these APIs can then be consumed by other web apps, outside services, etc. There are a bunch of potential options available, including using it as a potential building block in an Azure Logic App.

As for how do we setup an API app, it's actually surprisingly simple, and involves the following process. I'm not going to focus on the steps to set one up, as there is a great article in Microsoft's Azure documentation that does an excellent job of doing that. It can be found here.

Azure API apps are supported on the backend by Web API which is an ideal choice for creating RESTful services in .NET. I've done a previous post about the basics of Web API, which can be found here. Web API provides several benefits, but some of the biggest are the following:

• Client Driven Content Type: WCF Services require formal definition of end types, and can be rather inflexible, but the greatest strength of Web API is the fact that in the request header, the "Content-Type" is set, and Web API supports several different content types. But even gives you the ability to define your own formatters.  
• Convention over Definition: One of the paramount principles to RESTful services is that they provide a format where convention is favored over definition. Meaning instead of providing all kind of plumbing code to set up endpoints for your services. You rely on the routing and Http Verbs to define the actions within your services. Beyond that, they function the same as controllers for MVC.

Azure API Apps utilize Web API as the primary vehicle for supporting the API within the application. But it provides additional support by having out of the box built in support for Swagger, which provides JSON based definition of the controllers and methods available to the API.

This allows for a scenario where we get to have our cake and eat it too. We get all the benefits of having the RESTful services without having to define and maintain documentation based on the changes to the API. When the API is updated periodically, Visual Studio takes the opportunity to build the swagger JSON documentation. This provides the ideal best of both worlds.

As for my next post, we will see a Web API and an API interact with one another.  

Thanks again.