Blog Post

API Groups

Introduction:

API Groups feature provided by MuleSoft is used to organize and manage multiple APIs under a single entity. These APIs can be organized and managed based on the environment and organizations.

Benefits:

• API group can contain one or multiple APIs based on business requirements.
• The API groups can be published to exchange which makes it discoverable for the clients.
• We can create and apply SLA on the API group instead of adding it on individual levels.
• The API groups can be versioned and it can be promoted to different environments.

Setup:

• For setting up the API Groups we need to follow certain steps.

Note: For this document, we are considering the detailed view for which we will start from scratch.

Step-1: Create the APIs in the Anypoint Platform using the Design Center service. I have created two different APIs for this documentation purpose.

Step 2: We need to publish the APIs to exchange and make them discoverable.

Step-3: Now for the published APIs we need to create the instances using API Manager. Once the instances are created we can add them to the API group.

Step 4: We need to create an API group by going to API Manager and clicking on API groups.

Step-5: We need to provide a name and version for the API Group. These are mandatory fields. Now we need to provide a label for the API Group which should be unique.

Step-6: Once the API Group is created, we need to choose the Environment. Once we choose the environment we can see the APIs available in the specific environment in the dropdown. We need to choose the required API. Then we need to choose the API Instance for that specific API.

The same procedure we need to repeat for all the APIs we want to add to the API Group.

Step-7: Once the APIs are added we need to save it and then we need to publish it to exchange to make it discoverable.

SLA

Introduction:

• A Service Level Access (SLA) tier defines the level of user access for an API. When combined with an SLA-based policy, it determines whether accessing the API at a certain level requires approval. Additionally, it can restrict the number of requests an application can make to the API. To enforce SLA tiers, you need to apply a rate-limiting or throttling policy based on the SLA.
• To set up SLA tiers for an API version or manage applications requesting specific tier access, the API URL must be configured.
• SLA performance can be monitored to ensure that your APIs are meeting the standards set by the approved SLA tier.
• We can define a SLA tier for the API Groups and when the API is being accessed it will follow the rules defined for the API in the SLA tier.
• We can add SLA Tier level policy on the API Group and we can create the contract for the API Group itself in order to add the same policy for all the instances available.
• We can create separate SLA Tier level policies for individual instances as well. If any specific policy is not defined over the API instances the default policy on the API Group will come into play, else the individual policy has the precedence.
• Once we create the SLA Tier policy over the API Group we need to add the SLA Tier policy on individual instances in order to add the limitations on the APIs.
• To define the SLA over the API group we need follow the below steps.

Step-1: Choose the API Group version in which you want to add the SLA.

Step 2: Now click on the SLA Tier.

Step 3: Click on Add SLA Tier and fill in the basic names such as Name, description and Mode of approval.

There are two mode of approval which will create a contract for us.

Manual – Manually need to approve the request access in contract.

Automatic – Approves the request access automatically.

Step-4: Now we need to define the rules. MuleSoft provides rate-limiting rules as SLA.

We can define the rules for the group and individual APIs. The individual rule will take the precedence.

Once rules are added we can save it and we can request access for the API group to activate the contract.

API Contract

Introduction:

• API Contract also referred as API Instance contract is a direct contract created between the application and API.
• The contract will be created whenever the application request access to an API and the request is approved.
• The API contract works based on SLA, which can be created on API manager SLA tier.
• We can create a SLA with Manual and Automatic approval. In auto approval the request will be approved automatically and we get the client id and client secret.
• On the manual approval we need to grant the access by approving it in contracts of API Manager.
• We need to follow the below procedure to request the access and approve the request in the contract.
  
  

Step-1: Once the asset is available on the exchange, we can click on the asset and we have to click on request access.

Step 2: Automatically the API Instance will be populated and we can see the application name when our API and app are connected using auto-discovery. Else we need to provide the Application name.(In case of proxy)

If we have created SLA, we need to choose the appropriate one and then the contract will be created.

Step 3: We need to go to the contract to provide the permissions and we can get the client credentials from the application.For Manual approval we need to go to the contracts and we can see the pending approval message. We need to approve it to activate the SLA.

For automatic it will be auto-approved at the moment we request the access and follow the next procedure. There we can see the client Id and client secret after approval.

Once we receive the Client ID and Client secret we need to pass it as headers during the API call for a successful call to the resource.

Usecase:

The API groups can be created to manage and maintain the APIs under a single entity and assign SLA based policies on top of it. As part of this documentation, we have exposed two APIs and added the instances to API Group.

There is a SLA based rate limiting policy is assigned over the API Group, where the limitation is 1 call per 1 minute.

We are passing the Client Id and Client secret as header parameters.