SupportConsoleDevelopersStart a trialContact

Chapter 2. Launching your APIs

In this chapter, you will learn about some key steps to launch your APIs with Red Hat 3scale API Management. To use this guide, there are these assumptions:

  • 3scale has an internal API called API Backend, which is a backend.
  • 3scale has a customer-facing API called Echo API, which is a product. This is the API that you will expose through the Developer Portal.

The guide covers the following steps to launch your API product:

  1. Secure the product.
  2. Configure the product access policies with application plans.
  3. Engage your developers with a Developer Portal.
  4. Go live.

2.1. Paths to launch your first API

To begin working with 3scale, you can choose one of the three paths to launch and expose your API product. Your API product is the customer-facing API you are showing to the world.

The timing guidelines depend on the complexity of your API product and the resources you plan to dedicate to the effort. You will spend most of your time on refining your API product and preparing content for your Developer Portal. If you already have a stable product and content for documentation, you can go live within a week.

These are the paths to launch your first API product:

Prototype

  • Goal: Complete an end-to-end integration of 3scale with a simple API product, which will be exposed to the public.
  • Recommended for: This path helps you get a general overview of the end-to-end capabilities of 3scale. You must do this path before going through Basic. If you have successfully completed the onboarding wizard in the Admin Portal, you can skip this path and go to the next one.
  • Completion time: Less than an hour.

Basic

  • Goal: Complete all implementation steps to launch your API product in production.
  • Recommended for: If you want to go live with your API product in production and you have limited time, the Basic path will cover most of your needs.
  • Completion time: Less than a week.

Advanced

  • Goal: Optional extras after you have completed the Basic path, such as advanced control of your API product, and deeper customization of the Developer Portal.
  • Recommended for: If you have a more complex requirement or if you have covered the Basic path already, you may be ready to consider advanced options.
  • Completion time: Several weeks.

2.2. Following the Prototype path

You can follow through the Prototype path individually from end to end. Alternatively, you can choose to perform some steps from this path according to your needs. Each path can be independent, but Prototype, Basic, and Advanced paths build on top of each other.

2.2.1. Securing your API

You can prototype the 3scale access control layer within a few minutes, assuming one of the following cases:

  • In 3scale Hosted (SaaS), your product is publicly accessible.
  • In 3scale On-premises, your product is reachable from the 3scale installation.

Echo API serves as an example of a public product. It has the following features:

  • It is a simple API that accepts any path and returns information about the request, for example, path, request parameters, headers, etc., in the response body.
  • It is accessible at the following URL: https://echo-api.3scale.net
  • The first time you activate 3scale, a product is created for each existing API. In this first time, there is a one-on-one relationship between the product and the API backend. In other words, you will see: Echo API, a product containing API Backend.
Important

Only create a new application plans and applications if you do not use the predefined Echo API.

Prerequisites

Procedure

  1. Verify that your product is reachable. Example: https://echo-api.3scale.net/v1/fast/track

    • After the security layer is in place, you can hide or restrict access to the backend host.
  2. Navigate to [Your_product_name] > Integration > Configuration.
  3. For [Your_product_name], confirm that the private endpoint has been set in the default API Backend. Example: https://echo-api.3scale.net:443
  4. Click the button to promote to staging.

  5. Copy the cURL statement, which includes the user_key as the default credential, to make calls from the command line: 

    curl "https://api-2445581407825.staging.apicast.io:443/v1/fast/track?user_key=287d64924e6120d215b1000ac07c063b"

    You can make different calls. For example try another endpoint, adding the same user_key.

    Note

    You can get the API product keys from the application details page, located in one of the developer accounts.

    Your 3scale access control layer will now only allow authenticated calls through to your backend API.

2.2.2. Configuring API access policies with application plans

After following the steps under Securing your API, only authenticated calls are allowed through to your APIs. In this section you will apply policies to differentiate the rate limits.

In 3scale, applications define the credentials to access your product. An application is always associated with one application plan that determines the access policies. Applications are stored within developer accounts. In the basic 3scale plans only a single application is allowed; but, in the higher plans, multiple applications per account are allowed.

Important

The following prerequisites only apply if you create a new product and do not use the predefined Echo API.

In the following example, add a policy to the Echo API product used in the preceding section:

Prerequisites

Note

For the purpose of the following procedure example, the application plan is named Basic. Use the name you gave yours when you created the application plan.

Procedure

  1. Navigate to [Your_product_name] > Applications > Application Plans.
  2. In the Application plans section, go to the Basic application plan to edit one of the plans that was generated by the sample data after installing or signing up for 3scale.
  3. Under Metrics, Methods, Limits & Pricing Rules, select limits in the hits row, and create a new usage limit of 3 per hour.
  4. Find one of your sample applications, by navigating to [Your_product_name] > Applications > Listing. Ensure that the application is set to the Basic plan. If not, change plan on the application details page.
  5. Use the credentials for this application and repeat the previous sample call at least three times.

You have now successfully defined more restrictive access polices for all the applications on 3scale Basic plan.

2.2.3. Engaging developers with a Developer Portal

For the Prototype path, you do not need to create any documentation content. It is usually enough to check that the workflows meet your requirements.

While the product is in development and testing, you can disable the full self-service workflow with these steps:

  1. From your Admin Portal, navigate to the Audience space and click Visit Portal link in the Developer Portal menu.
  2. Create a test signup and walk through all the steps.
  3. Usually self-service is enabled by default. To change it, go to Audience > Accounts > Usage Rules and select the account approval required checkbox.
  4. Repeat the test signup walkthrough and verify that you need to approve the account in the Admin Portal before the user can log in.

You can now successfully customize workflows for your Developer Portal.

2.3. Following the Basic path

You can follow through the Basic path individually from end to end. Alternatively, you can choose to perform some steps from this path according to your needs. Each path can be independent, but Prototype, Basic, and Advanced paths build on top of each other.

2.3.1. Securing your API

For a full production implementation, you need to make some fundamental decisions about how to structure your product and implement integration with 3scale.

You have the choice of several authentication modes for product traffic. Consult the guide on the available options and configure the settings.

Important

After you set the authentication, you should not switch authentication modes because this action might invalidate existing credentials.

Additional resource

Hosted APIcast

  1. Follow the onboarding wizard after you log in to your Admin Portal for the first time.
  2. Continue iterating on your product configuration, such as refining access policies, until you have reached a version suitable for production.
  3. Promote your APIcast configuration to the production gateway.

Self-managed APIcast

  1. Deploy the APIcast gateway self-managed solution using the operator on OpenShift.
  2. Continue iterating on your API configuration, such as refining access policies until you have reached a version suitable for production.
  3. Promote your APIcast configuration to the production gateway.
  4. For further details about self-managed APIcast, see Installing APIcast.

2.3.2. Configuring API access policies with application plans

After following the steps under Securing your API, only authenticated calls are allowed through to your product. In this section you will apply policies to differentiate rate limits.

In Red Hat 3scale API Management, applications define the credentials to access your API product. An application is always associated with one application plan that determines the access policies. Applications are stored within developer accounts. In the basic 3scale plans, only a single application is allowed. In the higher plans, multiple applications per account are allowed.

In Prototype, you can only control access based on overall hits on your product. The flexibility of 3scale is evident after you start using custom methods and metrics to create more sophisticated tiers for your application plans and for deeper analytic insight to your product. For more details, see the analytics guide.

Important
  • The mapping between your API structure and methods or metrics in 3scale is logical. You can get reports of the product usage from 3scale if you define a consistent rule. You must determine the level of detail. Generally, you should aim between 5 and 20 methods/metrics.
  • The values reported to 3scale can only be incremented. You cannot set absolute values or decrease the counters.
  • After adding any new methods or metrics to 3scale, it is important to add the new system names to your integration point.
  • You can make changes, such as rate limits, at runtime without redeploying.

  • Only create a new application plans and applications if you create a new product and do not use the predefined Echo API:

Prerequisites

Note

For the purpose of the following procedure example, the application plan is named Basic. Use the name you gave yours when you created the application plan.

Procedure

  1. Navigate to [Your_product_name] > Applications > Application Plans.
  2. In the Application plans section, go to the Basic application plan to edit one of the plans that was generated by the sample data after installing or signing up for 3scale.
  3. Under Metrics, Methods, Limits & Pricing Rules, select limits in the hits row, and create a new usage limit of 3 per hour.
  4. Find one of your sample applications, by navigating to [Your_product_name] > Applications > Listing. Ensure that the application is set to the basic plan. If not, change plan on the application details page.
  5. Use the credentials for this application and repeat the previous sample call at least three times.

You have now successfully defined more restrictive access polices for all the applications on 3scale Basic plan.

APIcast deployment

  1. Go to [Your_product_name] > Integration > Configuration.

  2. Expand the mapping rules section and add the following mappings:

    Mapping rules
    Note

    The default mapping for "/" has been removed. If you use this default mapping, it will lead to double-counting of hits.

2.3.3. Engaging developers with a Developer Portal

You can find information to create and provide APIs using the Developer Portal. Consider writing your content in Textile or Markdown. Following are optional steps that you may want to consider:

2.4. Following the Advanced path

You can follow through the Advanced path individually from end to end. Alternatively, you can choose to perform some steps from this path according to your needs. Each path can be independent, but Prototype, Basic, and Advanced paths build on top of each other.

2.4.1. Securing your API

To secure your product, you have the following alternatives:

Advanced authentication mode: OpenID Connect (OIDC)

Secure your products using the APIcast integration with OpenID Connect for Red Hat’s single sign-on technology and Red Hat build of Keycloak. Applications in 3scale are synchronized with the Identity Provider (IdP). Currently, this is an end-to-end supported solution. It covers the main OAuth 2.0 flows:

  • Authorization code
  • Resource owner password
  • Client credentials
  • Implicit grant

2.4.2. Configuring API access policies with application plans

With the options listed under Securing your API, you ensured that only authenticated calls are allowed through to your product. In this section, you apply policies to differentiate rate limits.

In 3scale, applications define the credentials to access your product. An application is always associated with one application plan that determines the access policies. Applications are stored within developer accounts. In the Basic 3scale plans, only a single application is allowed. In the higher plans, multiple applications per account are allowed.

Alerts may be configured to send notifications by email or to the web consoles:

  1. Go to your API Settings page: [Your_product_name] > Applications > Settings > Usage Rules.
  2. Go to the Alerts section on the page. Here, you can configure the alerts that you want as a percentage of your rate limit levels.

3scale gives you the flexibility to decide on the level of rate limits:

  • Soft rate limits: Even calls above the limits are allowed through.
  • Hard rate limits: Calls are rejected before hitting your application.

APIcast defines hard limits by default. These can be customized in the Lua file to avoid rejecting over-limit calls.

2.4.3. Engaging developers with a Developer Portal

After you have completed the Basic path, following are two advanced areas you can explore for the Developer Portal:

  • Liquid markup provides tags and drops that provide direct access to system objects and allow you to introduce dynamic rendering of developer portal pages.
  • All 3scale system pages can be customized. This is for advanced users because the HTML is complex. Ultimately, you can customize virtually any page of your Developer Portal. Usually the default pages will be perfectly fine with some CSS changes.

2.5. Going live

This section describes the final checklist before the public launch of your API product.

Note

Raise request for the custom domain and email as soon as possible because they have a long lead time.

  1. In Audience > Developer Portal > Settings > Domains & Access, type a custom domain in the Developer Portal Site field.
  2. Optionally, type a custom outbound email address in the Outgoing Email field.
  3. Remove the Developer Portal access code.
  4. Click Update Account to save changes.

Following are some extra points for consideration:

  • Add pricing to generate earnings directly from your API product. This feature is only available for 3scale Hosted (SaaS) accounts.
  • Use insight from your product analytics, in your Admin Portal located under Analytics, to refine your application plans.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.