All Products
Search
Document Center

API Gateway:Manage environments

Last Updated:Nov 07, 2023

This topic describes how to manage environments on API Gateway.

1. Overview

APIs in each group can be published to three environments, namely the test (TEST), staging (PRE), and production (RELEASE) environments. This meets your need to call an API in different scenarios. For example, you can configure the test environment for an API. In the test environment, the API uses resources in the test environment as its backend service. This way, test engineers can simulate API calls without using the production environment.

To configure different environments for an API in the API Gateway console, you must perform the following operations:

  • Configure different URLs for the backend service for different environments. This way, API Gateway can forward an API request to different URLs.

  • Configure that the client must specify in which environment to call the API in each API request. API Gateway provides you with two methods. You can bind different domain names to the API group to which the API belongs for different environments. Alternatively, you can add the X-Ca-Stage header in API requests.

This topic uses two different backend service types, which are virtual private cloud (VPC) and HTTP, as examples to describe how to manage environments for an API based on two different client configurations, which are X-Ca-Stage and domain name.

2. Backend service of the VPC type + the X-Ca-Stage header

2.1 Preparations

In this example, two different VPCs are created. In each VPC, an Elastic Compute Service (ECS) instance is created for use as the backend server for the production environment or the test environment.

The TCP port 80 is enabled and NGINX is installed as the HTTP web server on both ECS instances. The instances return {"env":"test env"} or {"env":"relese env"} when they receive API requests over HTTP.

Note

This example is used only to describe how to configure different environments for an API on API Gateway. Therefore, factors that are important to a backend service in reality, such as high availability, scalability, and security, are not carefully considered in this example. We recommend that you take these factors into account when you deploy your own backend services.

2.2 Create and configure a backend service

Step 1: Create the backend-vpc-release and backend-vpc-test access authorizations for the two VPCs. The authorizations correspond to the production and test environments respectively. For more information about how to configure a backend service of the VPC type, see Create an API operation with a resource in a VPC as the backend service.

Step 2: Create a backend service of the VPC type in the API Gateway console.

  • Log on to the API Gateway console. In the left-side navigation pane, choose Open API > Backend Services. The Backend Services page appears.

  • In the upper-right corner of the page, click Create Backend Service. Select VPC from the Type drop-down list.

Step 3: Find the backend service on the Backend Services page and click Configure Backend Service and View Associated APIs in the Actions column. On the Backend Service Definition page, use the backend-vpc-test access authorization that you created in Step 1 for the test environment and the backend-vpc-release authorization for the production environment.

Note

The Backend Service Definition page provides four tabs, namely Draft, Test, Pre, and Production. You can view all APIs that use the backend service on the Draft tab. You can define a URL for the backend service in the respective environment on the Test, Pre, and Production tabs. You can also view the published APIs that use the backend service in an environment on the corresponding tab.

For more information about backend services, see Use a backend service to create and manage APIs.

Step 4: Create an API and publish it to the test and production environments. For more information, see Use a resource in a VPC as the backend service of an API operation.

Important

In the Define Backend Service step, set Configuration Mode to Use Existing Backend Service and select the backend service that you created in Step 2 from the Backend Service drop-down list.

2.3 Call the API by using the X-Ca-Stage header

  • To call the API in the production environment, you do not need to add the X-Ca-Stage header in the API request.

  • To call the API in the staging environment, you must add the X-Ca-Stage: PRE header in the API request. This example does not involve API calls in the staging environment.

  • To call the API in the test environment, you must add the X-Ca-Stage: TEST header in the API request.

3. Backend service of the HTTP type + domain name

3.1 Preparations

Use the two ECS instances created in the previous example as the backend servers of an API for different environments. The TCP port 80 is enabled and NGINX is installed as the HTTP web server on both ECS instances. The instances return {"env":"test env"} or {"env":"relese env"} when they receive API requests over HTTP.

Note

This example is used only to describe how to configure different environments for an API on API Gateway. Therefore, factors that are important to a backend service in reality, such as high availability, scalability, and security, are not carefully considered in this example. We recommend that you take these factors into account when you deploy your own backend services.

3.2 Create and configure a backend service

Step 1: Create a backend service of the HTTP type in the API Gateway console.

  • Log on to the API Gateway console. In the left-side navigation pane, choose Open API > Backend Services. The Backend Services page appears.

  • In the upper-right corner of the page, click Create Backend Service. Select HTTP/HTTPS from the Type drop-down list. You cannot create a backend service of this type in the China (Hong Kong) region and other regions outside the Chinese mainland.

Step 2: Find the backend service on the Backend Services page and click Configure Backend Service and View Associated APIs in the Actions column. On the Backend Service Definition page, define a URL for the backend service for the test environment and one for the production environment.

Step 3: Create an API and publish it to the test and production environments. For more information, see Use a backend service to create and manage APIs.

Important

In the Define Backend Service step, set Configuration Mode to Use Existing Backend Service and select the backend service that you created in Step 1 from the Backend Service drop-down list.

Step 4: Bind two domain names to the API group, one for the test environment and the other for the production environment, as shown in the following figure.

image.png

3.3 Call the API by using the domain names

  • To call the API in the production environment, use the domain name that is bound for the production environment in each API request, as shown in the following figure.

  • To call the API in the staging environment, use the domain name that is bound for the staging environment in each API request. This example does not involve API calls in the staging environment.

  • To call the API in the test environment, use the domain name that is bound for the test environment in each API request, as shown in the following figure.

Note: The domain name configuration takes precedence over the X-Ca-Stage header configuration. If you specify X-Ca-Stage in your request that is initiated for an API to which a domain name is bound, API Gateway routes the request based on the bound domain name, as shown in the following figure.