This course covers the Design Azure Web and Mobile Apps part of the 70-534 exam, which is worth 5–10% of the exam. The intent of the course is to help fill in an knowledge gaps that you might have, and help to prepare you for the exam.
Welcome back. In this lesson, we'll be talking about Web API.
Web API is a framework that allows us to create RESTful endpoints that we can use for just about any client we want.
Let's jump right in and see how we can create and deploy a basic Web API shell. We're gonna start out in Visual Studio and let's create a new web project, we'll give it a name and click Next.
Alright, here we're going to select the Web API template and we'll click Next again and then it offers to create an app service for us inside of Azure. However, we already have one so we're gonna click on Cancel and the project will take just a moment to get everything configured. When it does, we can check out the values controller which is a Web API controller.
Okay, here we are. Notice we have methods for common HTTP verbs. We have get, host, put, etc. So now if we compare this to an MVC controller, you can see that there's a bit of a difference there.
Let's change the strings here that will be returned from our list and get by ID methods and we'll change this one, okay great. Now, let's start this up and test it out locally. It's gonna take just a moment to load. Okay, there it is.
Now, we can see the results of our MVC homecontroller, though what we're interested in is our JSON API. So for that, let's fetch the results with PowerShell. We're gonna run the invoke RESTmethod and the first endpoint we'll hit is the list endpoint and you can see that it's returned the Web API and Azure values.
Now, if append a number to the end of the URL, we're going to see the string of Web API and Azure. And if we change the number again, we get the same string. Now remember, this is just a demo so that ID that we pass in really doesn't correspond to anything so it has no bearing on the results.
Now, let's get this running inside of Azure so we're going to right click on the project and select Publish and we need to import the publishing profile that I downloaded before the video started. Okay, if you wanted to download this for yourself, you can do that by clicking Download Profile in the Cloud Explorer pane.
Now, I need to verify the connection and there we go, it's perfect. Everything looks good so let's deploy. What this is doing is packaging up the app which basically means it's compiling it and putting the results in a zip file.
Okay, now with this running in Azure, let's go back to our PowerShell and we're gonna change the URL in our tester to see if we get the same results and there they are. So Web API is a framework for creating REST-based APIs rather easily. Just about every device can speak HTTP and that means we can integrate with just about everything.
Now, when it comes to locking down our APIs, we can use Azure Active Directory for authentication should we need to as well as our on premises version of AD with AD Federation Services and you can also use ACS, however that was deprecated and Microsoft's gonna roll that functionality into Azure AD.
So it's a versatile way to create APIs and because we're running in app services, we can scale up and out easily by increasing the size of the VM or adding additional VMs to handle the load. Let's talk about scaling a bit more.
Azure Web Apps provide multiple ways to scale web applications up and down. Azure Web Apps can be automatically scaled in or out, meaning that the number of instances hosting the web app can be decreased and increased automatically based on a schedule or some metric.
Now, this enables us to increase the amount of instances during known busy periods for an application and remove those extra instances afterwards, though maybe your traffic just isn't that predictable. So for this, you can scale by metric.
As an example, maybe the average CPU load so if the average CPU is at or above 80% for more than 15 minutes, you can add another instance to the pool. Auto-scale by metric allows us to scale based on the current environment metrics. These includes CPU, memory usage, disk queue and HTTP queue length as well as data in and data out.
Metrics are aggregated across all of the running instances hosting our web app and that's usually the average and this means that if one has a CPU of 80% and another instance is at 20%, it's gonna use the average of the two.
Each scaling rule that we define requires that we choose a metric such as CPU, a condition that can be something like greater than or less than and a threshold such as a percentage. You can also specify multiple rules using different conditions and metrics to combine them.
To avoid instances being added and removed more often than they probably should be, we can also specify a cool down period when we create auto-scaling rules and this lets the web app and the associated metrics settle down a bit and helps to avoid frequent scaling events.
When it comes to scaling up, there are some considerations. An instance size determines the processing power, storage and memory available to the app. It also defines the feature set such as deployment slots, the maximum number of instances, custom domains, automated backups among other things so the choice to scale up or down depends largely on the resources and features that are required.
It's important to note that when you change the instance's size, you're changing the instance size for the app service plan rather than the individual app and that change affects all of your web apps under that plan.
Alright, that's going to wrap up this lesson. In the next lesson, we'll cover mobile applications so if you're ready to keep learning then let's started with the next lesson.
About the Author
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.