 In this video, we're going to have a look at the features of the Red Hat Free Scale API Management Platform, which is a very versatile platform that allows you to control your APIs. It's obvious that many, many applications in the modern microservices architecture communicate by using all sorts of APIs, not just RESTful, but also other sorts. And HTTP being the bigotus protocol that mostly those applications use, it's becoming quite demanding to, first of all, provide a unified entry point for those APIs, but also it's a compelling option once a company develops a number of applications based around certain APIs to actually start offering those APIs to customers and end users. Now, sometimes, obviously, those APIs are a core feature that a company provides. And they may well be given away for free. But for certain more powerful functions, it's very lucrative to be able to create certain application plans that may include rate limiting, subscription fees, and authentication, obviously, as well. And it's actually an approach that has been widely adopted by enterprises the world over. So the three-scale API management platform is basically a set, again, of modular components that can be deployed in various topologies from being hosted in the public cloud to being deployed on-premise. And companies can use this product to control their APIs and literally bring them under control of some sort of governance that they can implement using the three-scale platform. With the platform, it's possible not just to implement traffic control, meaning basically filtering of which endpoints are available to what customers and such. It's also possible to monitor the use of the APIs. So analytics, access control metrics, performance metrics, implement monetization, support developers, also customer developers with automatic publishing of documentation and similar. And of course, since the entire API platform is built on OpenShift, it provides excellent OpenShift integration all the way. It's possible to easily integrate the three-scale API management platform with all sorts of backend APIs and use it to provide comprehensive security as an afterthought rather than complicate your applications and include all sorts of non-functional concerns into the development process. If we have a quick look at the three-scale API management web interface, we can see that in terms of managing APIs, we can have a number of application plans deployed to the platform whereby we can control things like trial periods, all sorts of fees, and of course even automatic approval. And in terms of audiences that we allow to use the API platform, we can also create certain usage rules such as, for example, account plans and service plans. So in terms of account plans, it's possible to create various accounts and users can also even apply for accounts on their own. And then if we drill down a sample application plan, we can see that it's also possible to set up some pricing rules per usage, even having certain limits, so different prices for different frequencies of use, and rate limits. So again, usage limits can be per period and may have a certain maximum value associated with it, such as, for example, 100 requests per hour. We'll be looking at some of those features in more detail in the upcoming demonstration where we deploy a simple REST API and use the three-scale API management platform to expose it to different users and, of course, provide them with different rate limits and even filter certain application URLs. An important feature of the three-scale API platform is the developer portal, where we can actually automatically publish the documentation for our API and even provide self-sign up abilities for the customers which want to sign on for the usage of our APIs. Let's have a look at how to configure the three-scale API management platform to allow us access to the backend API. So first, let's have a look at how it's deployed. So I'm going to open the OpenShift web console. Have a look at the three-scale project. Over here, we have several application components and, of course, roots as well that give us access to various three-scale modules. The one I'm going to use is the three-scale administration console, which I've already opened, actually, in another tab. So I'm going to log into it. We'll be presented with the default settings. If I have a look at the API configuration in the dashboard, we can see that some applications have already been pre-created. Applications, in this context, meaning the ability for end users to consume our API. But if I look at the integration settings here, I'll be able to see that in the APcast configuration, I'm actually using a default Echo API. So I want to change that, actually, to use my own backend application. I'm going to have a look at where that one is deployed. So it's running in a different OpenShift cluster with a different backend URL, which, for some reasons, I do not want to share with my end users. So if we look at the root for my application, it's the Twitter API presenter. So if I open this in another window and issue some sort of an API request like health check, you can see the application is responding. Let's issue a simple tweet request. There it is. So I want to expose this application of mine through the API management platform, which means, basically, I need to copy the base URL for my application and configure the private base URL to actually use my application's location. So that's just the base URL like this. The API gateway is going to expose the application that I've just configured on two URLs. One is called staging URL, which allows me to test my settings. And the other one is a production URL, which basically would be the external and the public access for API users. I'll leave the mapping rules as they are right now. I'm just going to confirm the settings and issue a test request just to see if that works. So the green bars at the left-hand side confirm that the settings I've entered are valid. And I've already got a simple Curl URL that I can use to actually see if my application is responding through the API gateway. So I'm just going to issue a test request. Note that I haven't actually published valid certificates, so I'm going to tell Curl to not complain about certificate trust. There we are. This is my health response. Let's do another API request slash API tweet in English. Here it is. Note that the request has a user key appended to it. This is a key belonging to the default pre-created user or consumer in the API platform. So if I have a look at the audience settings, we see that there already is a developer user owning one application. If I have a look at that developer's application, it's been assigned an API credential, which was used in the request that I was just making to test my API settings. So what I'm going to do next is I'm going to apply some limits to this developer's application. You see that this developer is actually using the API service, but is using the basic application plan. So this basic application plan already has a limit of 10 hits per minute. But this limit is indiscriminate. If I switch back to the API settings for a moment and look at the integration configuration, in the APCAST configuration, we can see there's a mapping rule that says any get request to any URL is mapped to a hit. Now back to the application plans. If I look at the basic application plan setting over here in the metrics, methods, limits, and pricing rules, we see that the hits metric actually has a limit imposed, which is set to 10 hits per minute. Now this is indiscriminate, which means that absolutely any request to my application will have been throttled at 10 requests per minute. What I want to add is basically no more than two requests per minute for each of the application languages exposed, so English, Spanish, and French. What I have to do for this is to create a new method that I'll be accounting. And then in the configuration for my API integration, define some new mapping rules. So I'm going to add a new mapping rule for slash API slash tweet slash en. And I'll map that to agile API get. Another mapping rule slash API slash tweet slash es. And yet another also maps to the same method. So these three mappings will basically will cause each request to any of those three URLs to count as one invocation of the agile API get method. I'll just update the configuration. There we go. Let's check that the settings are saved. And now I'm going to have to update the basic application plan and add a new limit. You see that the method has already automatically appeared under metrics, methods, limits, and pricing rules. Here we go. I'm just going to add a new usage limit. She's going to say we said two requests of any of those API methods per minute. There we go. I'm going to update the application plan. And let's see how this works. So note that I'm invoking the slash API slash tweet URL. Let's do another one, Spanish this time. And let's try the French one. Now this one should exceed the imposed limits. Not yet. Let's do another one. There we go. We've now exceeded the limits. And we're going to have to wait for a minute or so to be able to issue any more requests. Notice that the health endpoint is not included in the API get method. So health is not restricted. It is restricted by the other limit, which is 10 requests of any kind per minute. So a ways to go before we'll be notified that there is an exceeded limit. In addition to having the application plan equipped with some limits, we can also define pricing rules. If the user wants to exceed a certain volume, we can actually impose a pricing rule saying, for example, anything above 10 hits and up to 100 will cost $0.01. There we go. Now once the account using this plan has a pricing rule associated with it, signing up for the use of the application can be configured for the users to have to provide the credit card information. And then in the platform configuration, we can actually enable certain payment gateways and configure automatic billing for the customers to occur. So this was a quick overview of how to configure the three-scale API management with a custom API. Join us in the next video. We're going to have a look at how to bring all those technologies together in a fun and entertaining way.