Deploy and Configure API Management

0:00Welcome to the content on Azure's API Management Tool. API Management is a big, big resource, and that's one of the reasons why it takes a really long time to deploy. You might be familiar with other Cloud providers' API Gateway Solution and an API Gateway is a piece of the puzzle here. It is one of the resources that gets deployed when we deploy API Management. But there's a couple other things that come with API Management under the hood, and all of a sudden, understanding what this thing is really capable of becomes a big deal.

0:34That's actually gonna help you understand and determine which size API management resource is gonna work best for you. So in this set of videos what we're really focused in on is, first of all, what is API management, and it's not the management of APIs. The actual name of the resource is API Management. Then we'll talk about how do we understand what right sizing and capabilities are we actually gonna need when we start working with API management. Then we'll deploy an API Management resource, which again, clear some time for, it can take an hour or more to deploy.

1:09Then we'll actually work with implementing APIs in API management and more, policies, how do we control traffic as it flows through our API backbone? This is a huge thing to understand because especially in the platform as a service world, in the microservices world, what we typically see are computers or applications talking to other computers and other applications. This is what APIs do. It enables or facilitates the transfer of data from one app to the next, and that's really what makes Microservices work.

1:46So sitting at the center of it all is API management, and that's why we're beginning our entire journey with API Management first. So a big set of videos coming up right here, API Management is not a small resource to understand or deploy. So get ready as we start to explore one of the first clutch crucial core platform as a service offerings that exist in Azure, let's go.

0:00So, what is Azure API Management? Look, as part of your journey as a developer, as a learner, someone who's seriously considering going through with the certification exam, one of the things you need to get familiar with right now is documentation. Documentation is, I repeat, is your best friend in your professional journey, not just your certification journey, in your professional journey. There's great diagrams, there's code samples, there's quick starts to help you get up and running.

0:30Now, of course, CBT Nuggets is also your best friend and I'm here to break down some of these key concepts and help you understand and get started even quicker. This is how Microsoft documentation is typically broken down. You really wanna focus in, first of all, on the left-hand side of the menu. You'll see, first of all, an overview. This is gonna give you your crash course on what it is that this particular resource does. Then you'll see some service-specific items, like features availability, where would this be available or not available, and then service limits, basically depending on how much you wanna pay, what can it do up to a certain limit?

1:10Quickstarts are gonna help you do something quickly. In this case, these quickstarts are just helping you create the instance. It's not so much about working with it, which is why you have me, I'm gonna help you work with it. Tutorials then start helping you working with it, usually doing one specific thing. In the case of API Management, it can do about 20 specific things, about a million specific things, so tutorials are a great way to help you get started. Samples are also exactly what they say.

1:40Usually they're code samples, in this case, they show you policy snippets. That'll make more sense when we start talking about policies towards the end of this set of videos. Concepts are where they start to get into keywords and understanding the actual architecture and workflows of what this particular resource can do. And how-to guides are exactly what the name implies here, how to perform some specific type of action with API Management. Now, immediately out of the gate, what are the things that I want you to know about API Management?

2:12First of all, platform as a service. You are not going to be responsible for managing the operating system, the security patching, even the actual architecture itself. For instance, if you think about API gateways in general, what does an API gateway do? Here, let's actually draw it up on the screen. Here, I'll just fire up my terminal and go full screen in the terminal so that we can talk about this. At the end of the day, when we have APIs, we're gonna have lots of APIs, especially for our microservices architecture.

2:44We might have APIs running in containers. These containers might be using Azure Container Instances or Azure Kubernetes Services. We might be running them on Azure App Services, App Services, the closest thing that I could akin it to within the AWS ecosystem would be Elastic Beanstalk. Azure's app services are a platform-as-a-service web hosting solution where they manage all of the web hosting itself and you just ship your code to it, perfect for APIs.

3:19These could even be running as other platform-as-a-service offerings, like a function app for compute resources or maybe something like the Queue Storage solution for managing data in a queue. The point is, as you start to grow and mature with platform-as-a-service offerings or development within cloud providers like Azure, you're gonna have a lot of APIs, and maybe it's end users who are interacting with your function app or maybe it's other resources in Azure that are interacting with your function app.

3:55And maybe your function app is interacting with the queue service and maybe containers are listening to the queue service, and this is how it all starts to get out of hand. What API Management does is it sits in front of all of this stuff and it serves as a reverse proxy, I'm gonna put R proxy right there like that, and it gives you, the API administrator, a single pane of glass to look into all of your APIs that you have available in your entire ecosystem.

4:26This is the API Gateway solution. The API Gateway is your data plane. When a request comes in, it's gonna hit your API Gateway first, and the API Gateway is a layer seven inspection tool that can look at what's going on exactly with this particular request. Where was it destined? What headers did it have? What size was the payload? Any other additional things that we need to know about this particular request can help us determine what to do with it.

5:02The API Gateway from there can then pass it back to the resource that it's proxying. This can also serve as a point of SSL and TLS termination. Because it's platform as a service, you can think of it as nearly infinitely scalable, so it's a great candidate to offload that heavier compute operation of SSL and TLS encryption and termination. But beyond that, with the power to inspect what's going on with layer seven data, the payload itself, the headers, the actual URL that's requested, we can also, as the traffic is being moved to the backend or responses are being returned to the actual API Management, we can apply policies.

5:55Policies can add logic into helping API Management make decisions on what to do. For instance, we may have a request that comes in and it's typically destined for the Lambda function, but if the body size, the actual payload itself, is too big over a certain limit in kilobytes, we can use a policy to redirect it to something else like an app service. We can also check for authentication.

6:25If the correct authentication parameters were provided, pass it to the backend, otherwise, maybe redirect it to a queue for processing. By using one single resource to manage all of our APIs and all of their logic, we now have a single place where we can manage what goes on for all of the APIs in our entire environment without having to create a whole lot of custom code. I'm here to tell you right now, you might not see or very likely will not see any actual API code at all in this particular set of videos when we're working with API Management.

7:04The exception to that, I'll say, is policies right there for the longest time have been written in XML. So go ahead and prepare yourself mentally for that right now. When we start talking about policies, you'll start seeing policies written in XML. It's not that bad. It's not that bad, I promise, you're gonna see, but that's really the only code you're gonna see when working with API Management. Now, here's when I'm gonna clear the screen and start flipping things on your head. The API Gateway, right here I'm gonna put API GW, this was the data plane, and this is where data came in, data, new requests are gonna come in and hit the API Management URL first before they get processed and sent to the backend where they're also awaiting responses.

7:53But that's not the only thing you're getting when you get API Management, it's not just an API Gateway, you're also going to get the API Management plane itself. This is the brains of the operation or the control plane. When you start interacting with the control plane, this is you, the administrator, who's actually managing and deploying new APIs to the API Management. For instance, I've just deployed a new function app right here and now I want this to be proxied by API Gateway, and I wanna be able to write new policies for this function app.

8:34This is all handled in the control plane. The control plane allows you to manage your APIs, and with that comes one other additional benefit, the third resource that actually comes with API Management, the developer portal. Typically, when you create APIs, you're creating them for somebody else to consume, maybe that's somebody within your organization itself, a different dev team, or maybe you have something like a business-to-business arrangement where a customer or a partner, a business, needs to start interacting with your APIs.

9:15With the dev portal, you could actually publish your API specs to the dev portal. Your customers or partners register with the dev portal and then they request access to specific APIs on the backend. Of course, these will be accessed through the API Gateway, but when they need to understand what methods are available, what are the expected payloads, what are the expected parameters, what query strings are available, and in what data formats, what authorization or authentication is needed to actually access these, all of that is presented through the dev portal.

9:58It is a standing website that you manage and developers interact with. This could be public, this could be private, this could be integrated with Azure AD, as long as you get the correct licensing. So in your Azure AD, you could actually create some sort of a trust, so to speak, with your customer's domain, and then, in API Management, start granting privileges and permissions to your customers through Azure AD.

10:32Again, this depends on the licensing tier that you set for API Management. That's not a available feature until you get standard or premium. I wanna point that out right now, the integration with Azure AD doesn't begin until you get standard or premium, but nonetheless, these are the things that come with API Management. When you get API Management and deploy API Management, you get the data plane, which is what you expect, the API Gateway, but you also get the control plane and the dev portal with it.

11:03This is a really, really big resource, and this is why this is one of the rare times in Azure that it takes a long time to deploy this resource. It takes 45 minutes or more to deploy this. The last time I deployed it, it was like an hour and 10 minutes, but once it's up and running, you've got a really, really powerful tool at your disposal that can then start serving as a way to manage your various APIs and microservices that you can deploy throughout Azure.

11:34Oh, did I mention that this was fully scalable too? That was a big part of it, here is. Again, I can't reiterate this enough, you're not deploying a virtual machine here, you're not creating any IP address filters, at least not by default, you can, you don't have to worry about security patches, you're not managing any sort of NGINX server 'cause NGINX does serve as a great API gateway, no, all of that is done for you. You get to focus on the solution itself, shipping and managing your API exactly the way you want to.

12:09You get to focus in on your product and not all of the underlying overhead that goes with it. This is why we start with API Management on this journey and this is why we're starting with a platform-as-a-service offering. Now, in the next video, we're gonna roll up our sleeves and deploy it. We're gonna look at a couple different ways to deploy it, so let's get going. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00Okay, so where do we go to get logged into Azure? One more time, say it with me. portal.azure.com. Don't forget it. That's where we're gonna go. I'm gonna go ahead and get signed in. Use my multi-factor authentication code. And I'm gonna say, yeah, I wanna stay signed in. We're gonna be working here for a while. And we've got a little trouble with the portal. I'm gonna click Try Again real quick and it should, 9 times outta 10, this really does just flip right on for me here. Come on, come on there. There we go. See, you just hit Try Again until it works. Sometimes that happens, especially when I'm using my multi-factor authentication code and takes forever to get going.

0:36Okay, I'm gonna search for API management. We're gonna first do this from the portal so that way we can see how to do this from the portal. And then I'm also gonna show you how to do this with PowerShell. So I'm gonna search for API management services. That is what we're trying to deploy. And then we're gonna click right here, dead center, "Create API Management service." Okay, now get used to this dialogue as we go through this. Remember what I said, every resource needs subscription, resource group, region.

1:08That's every single resource that you deploy is gonna ask you for these three things when you get started. Now, subscription is not something I can just create on the fly, but resource groups actually are. I can create a new resource group by clicking Create New. I can give it a new name. I'll call this "knoxsapim". How about that? To put my API tools or my API resources, like grouped together, I'm gonna put them in that resource group like so. I'm also gonna put this in the south-central US, just because that's close to me.

1:41It's a nice close proximity. Now we're gonna go down here and choose the resource name. We'll call this "knoxsapim" again, just to give it a name. Knox's API management. Now the organization name, this is starting to get into that developer portal stuff right here. We need to be able to present to our outside users or the people who are consumer API, let them know who it is that they're actually working with and connecting to here. I'm gonna call this organization name "Knox's Data" and I'm gonna type in my administrator email, knox@knoxsdata.com.

2:16Now, the pricing tier. I did say we were gonna talk about this for a little bit, didn't I? If you actually click on the I right here, it'll tell you, "Explore the pricing tiers," and then you can click Learn More. When you get down here, scroll down to the pricing tiers and you see across the top, the column headers here, are each individual tier that you can have. Consumption is literally pay for what you use. It's not a flat fee per month. It is billed per execution. The first million API operations per subscription are included.

2:50After you go over 1 million API operations, you're looking at four point, you know, 4.20 cents per 10,000 operations. So if you extrapolate that by another million, it's $4.20. Now, if you don't want the lightweight serverless version, even though it's all platform-as-a-service behind the scenes, it's all really serverless for you. You can go up to Developer, which will give you a $48 a month charge, and we start to see where this really comes into play.

3:22The developer license is to help you get started developing with API management behind the scenes. If you're going to have development environments in your cloud, it makes a lot of sense to have the developer API management. For instance, you may have a development function app before it gets shipped into the production function app slot. The development function app should probably be behind a development API management tool. Notice the big thing about that though, no SLA.

3:53However, it does add cache, and it does add, well, one scale out units with automatic scaling. The other thing that I would point out, a big one that may be a factor for you in the consumption environment, is that this does have limits that apply here. Whereas when you start paying the flat fee per month, there are no limits of how much consumption or how much this can actually use. Now when you start to scroll down, you see some other cool things that come with this. The developer portal starts kicking in with the developer license, as opposed to using the consumption based license.

4:26You have the ability to use multiple custom domain names. Now the developer license is integrated with Azure AD. I know I said that that didn't start until standard, and I'm gonna stick by what I said on this one. This is really, this is still for a developer environment. This is not to be actually published out into production. This is really to help you build and test. Once you start shipping into production, that's when you start to see your Azure AD actually being consumed by developers in the standard license right there.

4:59Scroll down some more and notice some other things here like availability zone support, or virtual network support, multi-region deployment support. Even the ability to self host your own API gateway comes up, not until you get way down into the tiers towards premium and isolated. Now, the final thing to understand about Azure API management is that it works with the concept of units. And ultimately what you should be thinking about and how to scale this and properly size it is gonna be what is your maximum throughput, again, per unit.

5:33One unit is going to equal 500 requests per second in the Developer tier, 1,000 in Basic, 2,500 in Standard, and 4,000 in Premium. But remember when you start going higher in price, you also get the ability to scale out units. So you have one unit in Developer. You can scale out to two units in Basic. Four in Standard, 12 per region in Premium. So make sure you do the math and understand that when you get something like Basic, which does 1000 requests per second per unit, and we can scale up to two units, that really means you can get 2000 requests per second.

6:14I say this again, because look, the jump in prices is not insignificant. It can get pretty pricey. Although for very large enterprises, 2,800 bucks a month is not that bad. But to be fair, that is, again, per unit. Okay, so with that being said, I'm gonna jump back to create API management and I'm gonna leave this on the Developer tier right here. We'll choose to go to the next section right here where we have monitoring. We can turn on application insights right here.

6:46This digs a little bit deeper. We haven't talked about application insights yet. It adds extensible monitoring for you. When you're building your APIs, you can actually start logging more telemetry items and ship them directly into Azure for analyzing and analytics. Scale? Well, right here, we're not only using the Developer tier, so we don't have the ability to identify how many units we want to use. Managed identity. Ah, remember this? Yeah, does my API management tool need to access other resources in Azure like a key vault, like a database.

7:23In this case, we could give API management an identity that shows up in Azure Active Directory, and then very quickly assign it roles that give it permissions to other items. Did we want to integrate this with a virtual network or a private endpoint? Do I have virtual machines that need to access this API management as if it was connected on the local subnet? We could configure that right here. Protocol settings. Do we wanna force these specific kinds of TLS, or cipher encryptions, or HTTPS to be used right here?

7:58By default it wants to use the most latest and greatest. That would be TLS 1.2. But if we need to use older versions of HTTP or TLS or SSL, you could specify them right here. Lastly, there are tags. If we need to organize our resources, this is really useful for billing as well as analyzing resource consumption with our own custom tagging system. It's a key in a value pair that we could look up later. And then lastly, of course, is Review and Create. We're gonna fire off the Create button right there and boom, the deployment is underway.

8:29Like I said, this is gonna take a long time. I also said I was gonna show you another way to get this done. What we are gonna do now is I'm gonna fire up PowerShell and bringing my PowerShell terminal onto the screen right now we're gonna create an Azure API management instance directly using a PowerShell command here. First things first, though. My terminal needs to get authenticated and accessed into Azure. So I'm gonna say, "login-azaccount" like so.

9:00I'm actually gonna zoom in a little bit too so that we see the font nice and big "AzAccount," like this. Press Enter. And what does it do? It pops up a browser terminal right here. So I'm gonna go ahead and say I'm already signed in with this account. And just like that, authentication is complete. If I jump back to my PowerShell screen... Oh, too many PowerShell prompts right here. If I jump back to PowerShell here, let's go ahead and terminate that one, and it should have, there we go. It now shows me as logged in. Great. And it sees I'm currently using my pay-as-you-go subscription.

9:32That's really good. So now that my prompt here is logged into Azure, like so, what I need to do now is give it a commandlet that tells it what to do. The commandlet syntax, if you've never seen PowerShell before, is usually some type of verb, hyphen, then some object to do this verb against. In this case, when I say new, hyphen, that's basically saying create a new something. Now I have to tell it what to create. And the syntax we're usually gonna see with working with Azure resources always begins with A-Z.

10:08So it might be New-AzVm or New-AzFunctionApp or something like that. In this case I'm saying New-AzApiManagement. Let's go ahead and search for it. Tab to auto complete and it brings up New-AzApiManagement. Now we have to give it some parameters. These are named parameters, meaning the parameter has a name and we just specify it with hyphen, then whatever the name of the parameter is, like the name of my AZ API manager.

10:38I'll call this "posh" for PowerShell, "knoxapim." That way I know this will be the one that was created with PowerShell. I'll say my ResourceGroupName, if we spell it correctly, like this, and I can Tab to complete these, we can put this in my appdev resource group. I'll say -Location. That can be in let's say, southcentralus, all one word. Then we'll -Organization.

11:09Remember that was needed. And I'll call this "Knoxs Posh" for PowerShell. And then I'll say AdminEmail, like so. Quotes, and I'll say "knox@knoxsdata.com." And guess what? Press Enter, and there it goes. It's on the way. Now, like I said, this takes a long time to deploy, so don't close your terminal if you're going along with this. It's gonna take, you know, 45 minutes to an hour to deploy all of these resources. So I'm gonna stop recording right now, go get some lunch, and hopefully, by the time I get back, these resources will all be deployed and in the next video we can pick up where we left off.

11:48All right, see you in just a minute. Okay, so that went quite a bit quicker than expected. I started it at 10:32, I checked it at 11:10, so about 40 minutes in, and the resource has been deployed. It looks like it's good to go. I see... Now lemme take you in here 'cause the first time we've actually looked at a resource in Azure. So here we are. At the top right, right here at the top. You know, this section right here. This looks about the same for every resource that you see here. We've got an activity log, which usually involves like a security log, an audit log.

12:26Who logged in, who changed what. That's really what you're looking for here. IAM, or access control is where we delegate permissions to our internal staff to look at this resource in the first place, change this resource, you know, from a technical standpoint, maybe scaling or something like that. And then there's a security administrator on top of this who gets to delegate permissions to this resource as well. That's what typically happens there. Tags, Diagnose and solve problems, and then Events.

12:59So then we scroll down and we see, ah, here's APIs. That's what we're gonna be working on over the next few sets of videos, which is pretty cool. This is where we actually begin to work with our control plane. This is our control plane, effectively where we're going to implement APIs to be managed in our data plane and such, and such, and such, which is really cool. Then below that you've get the developer portal section. Notice, I really like pointing out that there is OAuth 2.0 and OIDC. That way if you need to connect to our clients or customers external identity providers and manage permissions that way, we have the ability to configure that right here in the developer portal.

13:39Then lastly, you have the monitoring section, which is where we can actually monitor the health, the status, and the consumption of the API gateway resource. We could also look at our deployment and infrastructure tiers right here, and this is also where we can come back and reconfigure any of this, like our pricing tier. We can actually change these at any time. We can scale this differently. We can go to a different pricing tier and then configure scale out on top of that from right here in the portal. Again, you should be extrapolating this, like obviously, the things we're looking at here are specific to an API management resource.

14:17But when it comes to virtual machines or SQL databases or service bus, anything like that, this menu on the left-hand side and the types of things that you can do from there and how you can reconfigure your resources or audit your resources, this is pretty standard. This is pretty much the same for all of Azure. So you're getting, even though this feels like this is my first time touching Azure, and this is our first resource being deployed, this is going to feel very familiar after a while.

14:49Okay, so now that the resources have been deployed, it's time to start using it in the next video. I hope this has been informative for you and I'd like to thank you for viewing.

0:00So fundamentally, one of the biggest things that API Management allows us to do is categorize or group all of our APIs into one place, and then from there, add logic or policies on top of it. Immediately, what you should be thinking is, now my requests are gonna make their way into this public gateway URL. Notice also, here's the developer portal URL, if you wanna start clicking in there and taking a look at what you can do, assuming you've already deployed this resource along with me.

0:30It's okay if you didn't, we're just saying, that's the idea here. So with traffic, new requests coming in, hitting this URL, we need to give it a backend to start serving, and this is what APIs do. So right here on the left-hand side, we're gonna publish the first API that we have. Now, how do we publish APIs? There's a few different ways, and you're seeing it right now. We have, we can define a new API from scratch with a classic HTTP-based REST API, we can define a WebSocket API, and we can define a GraphQL API.

1:04We'll cover some of these things in a later set of videos as we start to progress through the AZ-204 a little bit more. Now, the preference, probably the preferred way to actually publish an API is from an already existing definition. Most APIs today, especially if you're an API developer, come standard outta the box with the ability to scaffold a Swagger or OpenAPI definition for you. Similarly, if you're creating something like a SOAP API that is RPC-based, a WSDL is just part of the mix.

1:39So using one of these definitions is going to save you a humongous amount of time and effort when actually it comes to creating the API. When you choose to import it from a definition, API Management's like, "Ah, cool, I know all of the routes, all of the parameters, all of the payloads. I already know everything I need to know about this API, and it makes it a lot easier." I'm gonna show you both of the ways in this video. Then lastly is you could actually create this from an already existing Azure resource.

2:12And this is really preferable if you're serious about developing resources for Azure. In this case, your resources could be living in an App Service, we already talked about that, the Function App, or a container itself. Now, we haven't talked a lot about Logic Apps, and Logic Apps mysteriously are missing from the latest revision of the AZ-204 certification exam. My personal opinion, they're one of the coolest things in all of Azure, and should never ever be overlooked on any certification or in professional life.

2:48The point is, all of these resources expose an HTTPS endpoint, and when they're already deployed in Azure, it's really just as simple as pointing your API Management resource to that resource there so that it knows that it should proxy to those backend resources. Pretty straightforward. Alright, let's start with the very beginning, and we'll manually define an HTTP endpoint that API Management should proxy. Here's the thing, when we define it by an HTTP endpoint, could be any HTTP endpoint on the planet, couldn't it?

3:23It doesn't have to be hosted in Azure. This is really just serving as a proxy, and when requests come in to API Management, it's just gonna proxy it to this backend endpoint that we specify. Well, if that's the case, why not use one of the more popular HTTP endpoints in the world, the Star Wars API, what everybody uses to learn. See, we can absolutely leverage the Star Wars API, which is at swapi, Star Wars API, .dev/api endpoint. So I'm gonna copy this right here to copy this https://swapi.dev/api.

3:59I'm gonna jump back over here, and for the web service URL, I'm gonna paste it in like so. We're gonna call this display name Star Wars, let's call it Star Wars API. It'll automatically give it a name in the format that it wants, and if we need to put an API URL suffix right here, we can. Notice you have the ability also to flip this over to the full HTTP API creation process if you want. This allows you to give it a description, which might be useful for your developers who might wanna consume this.

4:30We can specify what protocols should be available or sent to the backend if need be. We can provide tags for this, like Star Wars, if that's what we need to do, to create a new tag for grouping our services together. Similar, if this needs to belong to a product that we're trying to deploy, we could specify a product that this needs to belong to. And then we can even specify which of our API gateways, assuming we had purchased the standard or premium tiers, where we have multiple gateways that we can scale, we could choose which gateway this needs to go in.

5:07Then we can even add versions to this API. That way, if I start to push new versions, and need to update the definitions in the backend here for API Management, we can keep track of the versions that we're publishing. Now, I'll flip this back to the basic tier for just a second, leaving things as they are, and I'll click Create. Now, since we chose the manual way of doing this, it's now on us to go through and define all of the different routes or methods that are possible with this particular API.

5:38It's on you to do that, this is why we like the definition. And the way we do that is we click the Add operation button right here, give it a click, and then we start to actually define what this is gonna look like. For instance, looking at the Star Wars API, one of the routes is to people. We can type people right here, forward slash, and just click Request, and we can see it returns a list of all people back to us, like so, see? The full payload of all people in all Star Wars comes back to us. So let's start to define this.

6:09We can call this display name all-people, like so. The URL to it is /people, like so. The request is a GET method, as opposed to a POST, or a PUT, or a PATCH, or a DELETE. And if we need, we can specify query parameters, headers, requests, and responses that should be sent back. When I click Save right here, we now see there is a GET request that's present available in the frontend. Similarly on the Star Wars API, we can also request planets like so.

6:44If I choose Request, we'll see planets comes back. Ah, there's planets right there. So jumping back here to my API Management, I'll add another operation right here. We'll call this all-planets, and I'll specify the path to the resource is /planets, like so. I'll click Save, and now, we have the planets operation that's available. So I have people and I have planets. Notice you can click on them over here under the operations and toggle between them.

7:16So how do I know that I configured this correctly? Well, of course, you can test it out. Let's test planets here for a second, since we just created all-planets. What I can do is I can click this Test tab right here, and under the Test tab, this is where I could add query parameters, headers, product scopes, request URLs. We could see exactly what request URL we're gonna be hitting. This is the request URL I'm about to request. So when I click Send, fire away, hold your breath, does this, oh, 200 OK response.

7:49Scroll on down, there is the response payload coming back, see? Really cool. You could even do things like trace the request if you wanted to do that. Now, you may have been spying here for a second. One of the cool things that the Star Wars API has the ability to do was to dig deeper and return a specific record here. For instance, if I wanted to return just the planet with an ID of one, how could I go about adding this parameter or this value to my API? Watch this, if I jump back to API Management, what I'm gonna do is I'm just gonna create a new operation real quick, and I'm gonna call this specific-planet, like so.

8:29And what I'm gonna do is on the GET request, we're gonna put planets/, wait, wait, it was /planets, /planets/{, and then we'll call it planetid, then closed brace, like so. When I scroll down immediately here, the template parameters has picked up I created a parameter called planetid. I can give this a description. I can also give this a type. Like if I wanted to, I could optionally specify a number.

9:02And then I could give this a value, like a default value of one, like so. So if I don't pass one in, but I hit this specific endpoint, it can automatically put it on there. Now, I'm not gonna worry about this. I don't want to use a default value. We'll choose no default here, make sure it's selected, and I'll clear out this number right here. This is all optional. As long as we have planetid right here, that's okay. I can click Save. Now I have a specific planetid that's been parameterized, and if I wanna test it out, I can come in here, and I can specify a value of one to add on to this parameter.

9:38So when I scroll on down, we see exactly what it is that it's gonna try and request to do. I'll hit Send to fire it off, and we get the one specific request that comes back now. So now, my API Management gateway has the ability to handle both a route for all planets as well as a specific parameterized planet. Pretty cool, right? Now, I did say I was also gonna show you how to import one of these from definition, and how much time that's gonna save you. Here's what I want you to do.

10:09Go to Google, and search for Pokemon API SwaggerHub. The very first link that comes up is gonna look kind of like this green symbol, and spy on the URL, it goes app.swaggerhub.com/apis/PokemonApi. That's where you wanna land. You're actually gonna get redirected to a site that looks like this. Over here on the right-hand side, go to Export, Download API, and choose JSON Resolved. That's the one you want to download. When you've got that JSON file downloaded on your local computer, that's what we're gonna use to import a new API over here.

10:44So I'm gonna add a new API, let's go ahead and add a new API, this is where we are, and I'm gonna choose to create from a definition that's an OpenAPI standard. And then I'm gonna select the file that I want to download here. So I'm gonna scroll on down to my Ps, there's the file. I'm gonna choose Open, and it immediately, you can see it immediately finds the display name and the name here. Now, you look at this base URL, knoxsapim.azure-api.net. Without anything tacked on to the end of it, it knows that by default, it's gonna be using the Star Wars API that I've already set up.

11:22To point new traffic to this new Pokemon API, this is what the API URL suffix does. If I type poke right here, we see now the base URL has a slash poke, and any endpoints that come after that are gonna be the ones that are for my Pokemon API. So look what happens when I click Create. It spins for a little bit, and then, I now have the full Pokemon API and all of their methods right here. So machines, abilities, Pokemon, IDs, Pokemon by name, and Pokemon by region.

12:01So I can go here, and now we can see, ah, this is how it's actually gonna work. So my endpoint, if you look at how the test would look, look down here at the test what the endpoint is really gonna look like. This is where the GET requests are now gonna be sent, /poke/api/v2/pokemon/{id}, and that's what's gonna get sent to the backend Pokemon API. This is what's really cool about importing from the actual definitions themselves, and lots of times, depending on the frameworks that we're using, these definitions write themselves.

12:36They're built in to the framework by default. Something like Python's FastAPI is automatically generating this Swagger definition as you develop the actual API itself. So importing this into something like API Management would be really easy. So now, we've seen how to create and publish and test APIs, including implementing parameters on top of that. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00So you might've been spying on this a little bit when we were actually creating the different operations that can be done. Let's pick on specific planet here for a second. Over here on the right hand side, which is kind of hard to see because I'm super zoomed in right now, I actually have to zoom out so that you can see this. We actually see the traffic flow like this. This is the request coming in over here. This is the response going out over here. Most API gateways and API management is not an exception in this case, give you the ability to inspect data as it comes into the front end.

0:39Do something with that data, make a decision, change it something before it gets sent to the backend. Then when the response comes back from the backend, we can do something with that response data, transform it, make a decision about what to do with it, and then send it back to the original calling client. This is not unlike anything else you've ever seen if you've ever worked with an API Gateway before, and sure enough, API Management gives you the exact same flexibility that you would expect in this case.

1:12Where it starts to differ a little bit is how you actually implement these. What we actually implement here are known as policies and policies are written in XML. That's actually what you see right there. Now, I'll say, I wanna pause right now and say, you know, it's been a couple years, probably two or three years since I last recorded API management, and they've already shown improvements on working with policies as we start to progress through our journey here. For instance, this is kind of nice, the ability to add a policy right here where you click on the add policy button to add an inbound processing policy.

1:52You can click on it and we can now actually look at some of the policies that we wanna inspect. For instance, do we wanna filter by IP addresses? Do we wanna rate limit based on an API key? Do we want to bypass the backend and just return a mock response? Do we want to enable course headers? Do we wanna add headers? Do we want to validate a JWT token? Ah, there's the authentication you were probably wondering about. Yep. If you want to integrate with something like Auth zero, you absolutely have the ability to grab and validate A JWT token directly in these policies.

2:34You can also custom make your own policies with XML as well. The big thing I wanted you to see in this video is just understanding the workflow and what policies are doing at each one of these stages. With inbound processing, we're really inspecting the original request and adding policies based on how that request should be formatted and structured. Should we validate the IP address that it's coming from? The JWT token that's in the header.

3:04When we look at the backend policies here, this is really any decisions we're making before it gets sent out to the backend. Lots of times, this is actually for route redirecting. I'll use this example already and I'm gonna use it again. What we can do, especially on the backend stage right here, is we can inspect something like the payload size and create a policy that chooses a different backend to send this to if the payload size is greater than a certain size, this is what a backend policy would be all for.

3:42And then outbound processing is looking at these responses and choosing what policy should go in here. Again, not terribly surprising to see things like setting and adding headers or changing headers before it goes back to the client, validating the content like the JSON schema or structure and validating the status code that we're getting back from the backend server. Here, I'll click discard so we don't add anything right now. When you ultimately are ready to see the full policy or custom type in your own policy, you can click the little code view right here and it'll actually bring up the XML policy itself.

4:21The thing I want you to really pay attention to here is this XML template is the full policy of all of the phases that we just inspected. There's inbound, there's backend, there's outbound, and then there's even an on error policy, something that you didn't see from that Gooey, what's the policy or what should we do whenever there's actually an error? For now, this is a quick look at what policies do and how they're kind of laid out and how you can get to them whenever we're actually working with specific operations.

4:56That's the last thing I wanna point out is each operation can have different policies and do have different policies, so you might be creating different policies for each operation that exists across all of your APIs if that's what you want to do. Okay, now that that's been set up, in the next video, we'll take a look at some examples of how policies can be written. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00So let's start to explore these policies a bit, huh? Let's see what we can really do to have some fun with this. One of the most basic transformations that we can do for an inbound request is maybe we're getting a request inbound that's authenticated through something like OAuth 2.0. This is gonna be something that we are going to either connect to the other identity provider, the the customer's identity provider, and get a claim from them that says they are who they say they are or perhaps we're actually leveraging something like Azure AD.

0:33Again, we kind of saw how that was gonna work when we were looking at things like the billing and pricing of the tiers. So once the user is authenticated, what then could we also do that has to do with authentication? Perhaps the backend actually requires authentication. Now, am I gonna be able to leverage the same OAuth 2.0 or Azure AD, or is this gonna be something like an entirely different authentication structure and scheme? The more likely scenario is the latter, where the backend isn't going to rely on authenticating the front end customer.

1:09We have already handled authenticating the front end customer. Now, we just need to make sure the channel is secure between the API gateway and the backend itself and this could use an entirely different authentication scheme. So what we're really trying to do here is we're trying to add in an HTTP authorization header into the request that goes to the backend. Let me show you how to do that. You'll be surprised at how easy it really is.

1:42We can go into the code view right here, and then in the inbound section right underneath base, I'm gonna press Enter and I'm just gonna paste in one simple line of XML. You're gonna see how easy it is. If I'm trying to do basic authentication to the backend, just username and password to reach the backend. I'll paste in the line. It is a tag called Authentication Basic with an attribute of username and password. Then you supply the username like knox and, you know, teaches or something like that as a password and it's gonna send this to the backend by default, that's it, that's all there is to adding an inserting an authentication header into the backend.

2:24Now, there are some other ways that you can authenticate to the backend. For instance, if you wanted to use something like a certificate, the certificate that might be hosted in something like Azure Key Vault. If assuming API management has a managed identity and can access the the actual certificate in key vault, it's just as simple as this. Specify the authentication cert, authentication certificate, and then the certificate ID to grab out of the key vault, just like that. See, that's really all there is to adding backend authentication into the mix.

2:59I'll click Save right here to save that and boom, see, now we've got the base policy and the authentication basic policy added into the mix. One more for good measures, I'll just press the plus and we'll add an IP filter into the mix. I'll add the IP filter right here, and we can say what the first and last IPS in the range are. Notice this is set to be the allowed IP list range. We could also flip this to be a blocked IP list range, which then allows everything else.

3:31So for instance, if I wanna block 1.2.3.4 and allow everything else, I can click Save right there and now I have an IP filter. Click back on the code view, and you can see exactly how this policy was scaffolded for you that was really, really helpful. So this is a basic example of how to start working with inbound processing policies, adding in authentication headers to be sent to the backend, as well as performing filtering operations from the front end.

4:02I hope this has been informative for you, and I'd like to thank you for viewing.

0:00Now one thing, final thing I wanted you to leave, one final thing I wanted to leave you with. That was hard to say. Is I wanted you to know that we've just scratched on the surface when it comes to policies. Yes, when it comes to policies, you got some really useful ones right here out of the gate that you can help get started with. But there are an extraordinary number of policies and XML tags that you can work with. And like I said, documentation is gonna be your best friend.

0:30Here's a perfect example why. When I scroll on down here, click under reference and then go down until you see API management policies. Flip that open, and these are all the tags that you can work with. Now, these are really useful tags. When we see things like set header right here, we're thinking, "Okay, well I got the idea of what set header is gonna do, but it would be really nice to see some examples of really useful policies that other people have come up with".

1:04Well, scroll back up just a hair on the left hand side of your menu and then under samples go to policy snippets. This is actually gonna take you into like a VS code plugin installation, but right here the top folder on GitHub is examples. And when you click on this, this is where your world kind of gets flipped upside down for a second. Yeah. "Parse A JWT token using expressions. Put a file onto a blob storage account.

1:38Log errors to stackify. Forward an event to the Azure event grid. Encrypt data using expressions". Hopefully I'm kind of drilling this home at this point that you see. There's a lot that you can absolutely do here. One of my favorite ones though is route requests based on size policy. Give that a click right there and start to explore what this is. Remember, I've mentioned this a few times now, that if a payload comes in that is too big, for instance, over 256 KBs, which is the limit of Azure Service Bus, we may wanna redirect that message somewhere else.

2:19That's exactly what we're looking at here. A service bus really is just a gigantic message queue, and the thing that makes it work so fast and so well, and so performant is limiting the size of the messages. So in this case, if we're using our API Gateway to serve as a proxy to service bus, then we need to validate that the file or the payload size that's coming in isn't too big. So what this does is it uses an inbound policy and then in the base section, or underneath the base section, we're gonna set a variable at runtime.

2:54And the name of that variable is gonna be body size. And that value is gonna come from the message itself's request headers, content length. That's gonna tell you what the body size is of the payload that's coming in. From there, we're gonna say choose when we're gonna find as an integer for that body size value. If it's greater than, or if it's less than 256,000, then we're not gonna do anything.

3:25We close our wind block right there. We're just gonna let it go to the backend because it was under the 256K. Otherwise, we're gonna rewrite the URI and change to a different backend service that we're using right here. See, this is a perfectly good example of when we might want to use a complicated policy, and these policies can be complicated yet very powerful. So I wanted you to be aware. First of all, there's two really important resources.

3:55The examples are great, but you also need to be aware if you keep hitting back a few times here, you also need to be aware that all of the potential policy tags that you can use, they exist under the API Management policies reference. Understanding how to use these is gonna be extremely powerful. And you wanna spend some time thumbing through these. Just look at the names, and either guess what they do or say, "Oh, that would be really useful. Let me see if I can find an example where they've already used it".

4:28One of those is gonna be powerful and useful for you. So before we signed off an API Management and moved on to the next topic, I wanted you to be aware that there's more underneath the service, service, underneath the surface of API management policies, and using this documentation right here to look at what these different policies can do in addition to the examples or the sample code, that's gonna be really helpful for kick-starting your journey into defining policies for each of your API's operations.

4:59I hope this has been informative for you, and I'd like to thank you for viewing.