Defining Rate Limits in an assembly – Digital Transformation with IBM API Connect

As if you didn’t have enough flexibility and granularity in your Rate Limiting, APIC allows you to get even more granular by configuring a Rate Limit on the assembly of an API itself. When you configure a Rate Limit on the assembly, you are marking a specific point in the process to apply this Rate Limit. This will supersede all Plan and API Rate Limits and once the threshold is reached at that point in the assembly, all processing is stopped. Since this Rate Limit policy is configured on the assembly, all processing before the policy will be executed. However, any processing that’s configured after the Rate Limit policy will be aborted if the Rate Limit threshold is exceeded. As you will see when we discuss the different options for defining the Rate Limits for this policy, this type of Rate Limiting could be considered a consumer or a provider Rate Limit. This is because your Rate Limit policy can refer to a specific Plan or a consumer-agnostic Rate Limit defined elsewhere. Let’s take a look at how to configure this and how it works.

As you develop your API policy flow, you will notice an available policy named Rate Limit. Just like any of the other available policies, you can simply drag this policy to any point in the flow. It is at this point that the Rate Limit you define will be enforced and if the defined threshold is exceeded, its execution will be aborted.

Let’s look at an example where you have some processing logging in your assembly and then a GatewayScript to do some custom processing. Perhaps you want these policies to execute with no Rate Limit at all, but you need to rate-limit calls to the backend to protect the backend server from being overwhelmed. In this case, you can add your Rate Limit policy after the log and gatewayscript policies but before the invoke policy, as shown here:

Figure 10.14 – Adding a Rate Limit policy

As you can see, we added this Rate Limit policy just before the invoke policy so that if our defined Rate Limit is exceeded, our policies before the Rate Limit policy will execute, but the transaction will be aborted before the invoke policy.

Now that you have decided where you would like to enforce the Rate Limit, you will need to configure the Rate Limit’s threshold and its parameters. Unlike the previous Rate Limit configurations we have discussed, when you are configuring a Rate Limit policy, you will simply refer to a configuration that specifies these parameters. This is specified in the Rate Limit policy configuration, under the Source dropdown. Let’s take a look at the different options for referring to a defined Rate Limit configuration within your policy:

  • Plan default: The rate and burst limits that are defined in the Plan default that the calling client or application is subscribed to.
  • Plan by name: Apply the rate and burst limits as defined in a previously configured Plan.
  • Gateway by Name: Refers to an object defined on the API gateway of the apigw type called apiconnect.
  • Catalog by Name: Refers to the rate and burst limits defined on the API Gateway within the api-collection object. This particular object on the API Gateway represents the APIC Catalog.

As you can see, there are several different locations where you can have rate and burst limits defined that you can refer to from your Rate Limit policy. Each requires configuration and can be defined in very different manners. Let’s take a deeper dive into how we can configure these limits and then refer to them from our Rate Limit policy. The first option that you can select, Plan default, does not require any further discussion as it simply refers to the default Plan Rate Limit for the consumer, which you already know how to define.

Configuring the Plan by name option

As we have already discussed configuring Plans and Rate Limits within this chapter, you should already be familiar with how that works and how to configure them. If you need your Rate Limit policy to refer to the count and burst limits defined within specific Plans, this is the option you would choose as you can reference these limits within your Plan from your Rate Limit policy. However, these limits will not be the same limits you defined in your Plan previously as there are specific rate and burst limits you must use in the assembly that’s defined within your Plan. These are appropriately labeled Assembly count limits and Assembly burst limits and can be found at the bottom of your Plan’s configuration, as shown in the following screenshot:

Image 10.15 – Assembly burst limits and Assembly count limits

Here, you can see that we have added a burst limit named AssemblyBurst and a count limit named AssemblyCount. A count limit is the total number of requests allowed to the API. Once you have defined and saved these limits, you can reference them by name within your Rate Limit policy. The following screenshot shows a Rate Limit policy where we have added a count limit and burst limit referring to the assembly limits we have defined by name:

Figure 10.16 – Rate Limit policy referring to assembly limits

With that, you’ve learned how to refer to different limits within different Plans by referencing them in your Rate Limit policy. Now, let’s learn how to define different types of limits on gateways and reference them from within a Rate Limit policy.

Related Post

Leave a Reply

Your email address will not be published. Required fields are marked *