Illustrative Example in This Document

URL: http://10.2.3.4:80/app/apiname

METHOD: POST

Create API Gateway Staging and Prod Routes

To ensure seamless API management, we necessitate a few default API gateways, specifically tailored for staging and production environments.

These gateways essentially function as APICAST routes, enabling us to regulate traffic flow to your API hosted on a specific APICAST instance.

For a comprehensive understanding of APICAST, please refer to https://access.redhat.com/documentation/en-us/red_hat_3scale_api_management/2.3/html/deployment_options/apicast-overview.

Backend Configuration

• Establish a backend, representing the domain and port of the API, which can be shared by two or more products.
• This URL will be masked, and a 3scale URL will be provided post onboarding to access this API.

In this example, we are considering the base URL as: http://10.2.3.4:80/app.

Product Configuration

A product is a precise path that specifies the exact API service we intend to onboard and monitor.

Once the product is created, you can navigate to integration -> settings to access the configuration details for deployment, authentication, and gateway responses.

The staging and production URLs indicate the service route names.

Note: The staging and production-base URLs can be configured only if the subdomain name remains unchanged.

Authentication Mechanisms

In 3scale, API authentication can be achieved through three distinct methods, outlined below:

1. API Key (user_key) The application is identified and authenticated via a single string.
2. App_ID and App_Key Pair The application is identified via the App_ID and authenticated via the App_Key.
3. OpenID Connect Utilize OpenID Connect for any OAuth 2.0 flow.

We can gain a deeper understanding of the authentication mechanism from the following link: https://access.redhat.com/documentation/en-us/red_hat_3scale_api_management/2.1/html-single/api_authentication/index

Authentication Credentials Location

In this section, you can specify where to send the authentication credentials required for verification in the incoming request.

Method Configuration

Each method in this API retrieves data on its individual usage, triggering the built-in Hits metric. Usage limits and pricing rules for individual methods are defined within each Application Plan.

In addition, various performance indicators can be tied to each method, and different analytics can be established. For example, data transfer performance metrics.

Navigate to PRODUCT -> Integration -> Method and metrics – > New Method.

A method must be correlated with one or more URL patterns in the Mapping Rules section of the integration page to accurately tally specific calls to your API.

Configuring Metrics

Hits are built-in performance indicators that all methods report to. You can add additional top-level metrics here to track usage that shouldn’t increase the hit count. A metric is correlated with one or more URL patterns in the Mapping Rules section of the integration page to accurately tally specific metrics.

Navigate to PRODUCT -> Integration -> Method and metrics – > New Metrics.

Defining Mapping Rules

The mapping rules govern operations and can be correlated with previously-defined methods/metrics. They can be correlated against the pre-defined hits metrics to increase the count on API hits.

Configuring an Application Plan for a Product

Application Plans establish the rules (limits, pricing, features) for using your API; every developer’s application accessing your API will operate within the constraints of an Application Plan. From a business perspective, Application Plans enable you to target different audiences by using multiple plans (i.e. ‘basic’, ‘pro’, ‘premium’) with different sets of rules.

The product configured requires an application plan mapped to it to manage the subscriptions of the accounts and their applications hitting the API.

Understanding the Distinction Between Method and Metrics

Method

Methods are specific to particular URLs. The increment of hits occurs for path matching methods by invoking the Service Management API of 3scale.

Metrics

We can measure any numerical value to be incremented for an API application by defining a custom metric. Any client (not just the API gateways) can increment a custom metric using the Service Management API.

This metric doesn’t necessarily require a URL; a simple string-based name will suffice.

API Deployment

Once all configuration is complete, we need to deploy the API to staging and production environments.

Navigate to Product -> Integration -> Configuration -> APIcast Configuration -> Promote to Staging. (Verify all configuration in this section before promoting it)

Upon promoting the API from Staging to Production, the subsequent screen will display the entry points exposed by 3scale for accessing these APIs.

Configuring Account Settings

The consumer of your API will be established as a distinct account.

For instance, we have established the following account:

A user is added during the account setup process, and additional users can be invited via email from the following screen.

( Note: this requires SMTP setup to be done in Openshift for the 3scale project)

User administration can be accessed from the following screen:

The APIs available on 3scale will be made available to an account as applications.

The application setup is as follows, where we can observe a section labeled “API Credentials”; the provided key will be used to authenticate the account and allow the request to proceed.

Every application set up for an account is assigned a unique identifier.

The applications accessible to an account can be controlled via the subscriptions tab, as shown below, where an API management administrator can modify plan and subscription details.

(Important Note: When an account is tied to a default plan, it cannot be unsubscribed, as the API has explicitly designated that plan as the standard for all users)

API Gateway Hub

This dedicated platform offers a user-friendly interface for API consumers to seamlessly onboard and select their preferred subscription plan. The layout of the portal can be tailored to meet specific needs using CSS and JavaScript customization scripts.

The REST API can generate comprehensive Swagger documentation within this portal, providing subscribers with instant access to detailed information that fosters a more profound understanding of the API they are utilizing.