AZ-304 Microsoft Azure Architect Design – Design for API Integration Strategy

1. API Management

So we’re going to wrap up this discussion of deployment, migration, and integration. Talking about API integration. Now, you know how there’s companies out there that will allow developers, thirdparty, developers to use an API to interact with their service. A good example of this is actually Microsoft Azure. As a developer, you can integrate with Microsoft Azure if you’re authenticated using their Azure API. The Azure API gets wrapped up in talking about Azure SDK.

So that if you’re using net, PHP, Python or Java, any of the supported languages and use the Azure SDK, when you’re calling those methods and properties, you’re actually integrating with the Azure API. But there is an actual restful API. So if you know the URLs and the URL formats, you can interact with Azure using their API. Now, the challenge with providing an API for your company is basically going to be there’s a security challenge. There’s going to be people who are using your computing resources and you can’t control that.

So I worked with a company who wanted to provide an API and we had a hackathon around that as well. And we basically had to go out and find a way to wrap our APIs in certain throttles and controls and making sure that people can’t take down their back end systems by overwhelming the API with traffic. As an example, Microsoft does provide a service called the API Management Service or sometimes API gateway. That basically wraps a back end APIs in some very friendly, secure wrapping. So we can see on screen I grabbed this from my Microsoft Ignite talk that on the left we have developers. And developers can go to your website, discover, learn, register, try all of your APIs. API management provides a developer website for that. They can then decide to sign up. They can register. You get to approve them and then you can assign them limits, how many calls per hour that they can have, et cetera. They have to use their key in order to call your API.

It’s also a gateway where you’ve got your coded APIs, logic apps, functions, service fabric, web apps, virtual machines. All of their APIs run behind the API management gateway. And it gets integrated and it becomes all one facing the general public. They don’t know that they’re calling a logic app or a service fabric. Finally, as a development team, as managers, you get to see the reports, analyze usage, et cetera. So there’s services for the consumer, services for the publisher, and services for the API itself. I look at this really primarily as a security layer around a public API. So, like I said, if you are brave enough to provide API that someone can go to and just start calling, then you’re inviting hackers into the back end of your application. You’re inviting denial of service attacks. And so putting a security layer in front of that makes good sense. It’s also a developer portal, so it will host the documentation. If you use a tool like Swagger to generate the documentation for your API, then it’s going to basically host those files. It contains all of the gets and the posts and the syntax.

And you can actually, within the website, the developer can actually try it. They can put their API key in, pass some parameters, hit tests and see what comes back. Now, it doesn’t always have to be from an open public. Like anyone can come and use your API. It may be that you have partners. So you’re a company and you want to provide Walmart with the access to your back end software. And so you can wrap your APIs in API management and provide their credentials only to Walmart. And as we saw in the diagram, it’s got the benefit of having its own URL. And that can be a standardized thing. So you can have www dot your website Comair and everything after the API gets sent to the API. And so by standardizing the URL of your APIs, it becomes from all the different sources, the VMs and the web apps and the source fabric apps and the functions. No matter who’s generating the results for that method, it can all have the same name. And also this supports transformations. And so you might have an API that you want to provide in JSON format, but the API that’s internally is in XML format. And so there’s XML to JSON transformations. You can search for a string and replace that with something else. You can modify the data, modify the headers.

We’re going to talk about that in a video coming up. But the transformations of the back end to the front end can really help standardize your service. It can protect you. If you don’t want your APIs having certain headers in the response that indicate what operating system and what language it’s running in, then you can strip those out using API management. And finally, just as important, you want to see people are using your APIs. So you can give out your developer keys to ten individuals and you will know from the analytics and from the reports who’s actually using it, how many times a day they’re calling it, who’s not using it, and et cetera. So API management is just really a flexible way. If you’ve got any concept of wanting to provide a third party access to your back end through an API, you really should be looking at API management to protect all of that.

2. API Policies

So, continuing on talking about the API management tool, let’s talk about policies. So in the last video we mentioned about how the API management tool can do transformations. And this is one of the really neat features of it if you need to modify your API before the general public sees it. So the API management tool can do four different types of policies. There are inbound, outbound, backend and on error. And this diagram shows you the four types of policies. So when the end user, the consumer, which is a developer, a third party application, calls your API, you can have a policy when they receive that traffic. The back end policy seems to be a common policy that is inbound and outbound, and then there’s an outbound specific policy. And if something happens, if the API fails, what happens on errors? Maybe you want to have a very friendly error message wherein the back end API is going to throw up a very ugly error message.

So this is an example of the policy. So we can see on the left it’s an XML file. It has inbound, back end, outbound and on error sections of that file. And you just add basically one of the templates. So on the right is basically pick a template that you want to choose. This happens to be Restrict Caller IPS, and it adds this IP filter XML node into your document. And you get to choose whether you want to allow or forbid traffic from what IP address is allowed, or whether it’s a range of addresses. And you can edit that template as required. And so it’s an example of basically forbidding trap. Maybe you only want Walmart to access your API and you don’t want anyone else.

And so you know what IP address Walmart is calling it from, or what range of IP addresses they’re likely to call it from. And you can restrict your API calls just to that. So that would be a security feature. We can see that there’s other access restrictions. We can limit the call rate. So when the developer registers, they’re given a key. And so you can give to each developer their own unique API key that they must use every time they call your API.

So you can basically say, well, you get 100 calls per hour based on this key. And the API management tool is going to make sure that people don’t call that API more than 100 times an hour, if that’s the limit. So that’s called limit call rate by key. You can also limit the call rate for your entire subscription. So let’s say your fear is, no matter how many developers you have, that there’s going to be 10,000 requests per minute and it’s going to overwhelm your back end. And so being able to say there’s an overall limit, not developer specific, but for everyone in terms of the number of calls you can allow through, we already talked about restricting the IP addresses. There’s also a usage quota.

And so you can basically give the people their limits. And finally JWT, which is the Java token, which is a security thing. So if someone has to log in first, and then they have to pass a token in order to get access, we can have that as an access restriction. Now, those were access restrictions. These are a bunch of other policies. That’s just one sample of what you can access. So there’s Advanced policies, authentication, caching, if you want to, let’s say a particular API call happens so frequently and the data doesn’t change. And so you want to implement Caching. I think we talked about this in the redis section of the database section of this course.

But basically implementing Caching is one good way of basically stopping an API from being overcalled. There’s also the way you have cross domain support cores, and whether you allow that or you don’t allow that, et cetera. And the transformations we talked about JSON to XML, XML to JSON, adding headers or moving headers, you can just replace the whole body of what’s returned with something special, like, say, with the on error policy. You can say on error, I want to replace the body of what comes back with I’m sorry, we’re having a problem, try again later. You can do all of that within the transformation policies. So API management pretty cool. And policies are how you can modify, control and protect your back end APIs.

• Category: Uncategorized