Updated on 2024-04-03 GMT+08:00


APIG is a fully managed service that enables you to securely build, manage, and deploy APIs at any scale with high performance and availability. With APIG, you can easily integrate your internal service systems and selectively expose and monetize your service capabilities.

APIG provides dedicated gateways and shared gateway (for existing users). For details about how to use dedicated gateways, see API Management to Auditing. The shared gateway has been brought offline and can be used only by existing users. For details, see Shared Gateway (for Existing Users).

General Procedure

The following figure shows the procedure for using APIG to host APIs.

Figure 1 APIG

You can expose your API services or obtain and call APIs of others through APIG.

Exposing APIs

Enterprises or developers selectively expose and monetize their services and data through APIG.

Figure 2 API exposing process
  1. Create a gateway.

    A gateway is an independent resource space where all operations are performed. Resources of different gateways are isolated from each other.

  2. Create an API group.

    Each API belongs to an API group. Create an API group before creating an API.

  3. Bind a domain name.

    Before exposing an API, bind an independent domain name to the target group so that API callers can access the API.

    You can debug the API using the debugging domain name allocated to the group to which the API belongs. The domain name can be accessed a maximum of 1000 times every day.

  4. Create an API.

    Encapsulate existing backend services into standard RESTful APIs and expose them to external systems.

    After creating an API, configure the following settings to control API access:

    • Traditional policies
      • Request throttling

        Request throttling controls the number of times an API can be called within a time period to protect backend services.

      • Access control

        Set a blacklist or whitelist to deny or allow API access from specific IP addresses or accounts.

      • Signature keys

        Signature keys are used by backend services to verify the identity of APIG.

    • Plug-in policies
      • CORS

        This policy provides the capabilities of specifying preflight request headers and response headers and automatically creating preflight request APIs for cross-origin API access.

      • HTTP Response Header Management

        You can customize HTTP response headers that will be contained in an API response.

      • Request Throttling 2.0

        This policy enables you to limit the number of times an API can be called within a specific time period. Parameter-based, basic, and excluded throttling is supported.

      • Kafka Log Push

        This policy pushes API calling logs to Kafka so that users can easily obtain them.

      • Circuit Breaker

        This policy protects your backend service when a performance issue occurs.

      • Third-Party Authorizer

        You can configure your own service to authenticate API requests.

  5. Debug the API.

    Verify whether the API is working normally.

  6. Publish the API.

    The API can be called only after it has been published in an environment.

Calling APIs

Enterprises and developers obtain and call APIs of other providers, thereby reducing development time and costs.

Figure 3 API calling process
  1. Obtain an API.

    Obtain the API request information, including the domain name, protocol, method, path, and authentication mode.

  2. Create a credential.

    For an API that uses app authentication, create a credential to generate a credential ID and key/secret pair. Bind the credential to the API so that you can call the API through app authentication.

  3. Obtain an SDK.

    Use the SDK to generate a signature for the AK/SK and call the API.

  4. Call the API.

    Call the API using its access address and perform authentication based on its authentication mode.