2. In the service list, click the name of the target service to view it.
3. In the service details, click the Manage API tab and choose to create a General API based on the backend business type.
4. Click Create for subsequent configuration.
Step 2. Perform frontend configuration
The frontend configuration of an API refers to the relevant configurations provided for external access, including the API name, frontend type, request protocol, HTTP method, URL path, and input parameter definition.
Configuring basic frontend information
API Name: name of the API you create, which must be unique within the current service and can contain up to 60 characters.
Frontend Type: supports HTTP&HTTPS and WS&WSS.
Path: You can write a valid URL path as needed. If you need to configure dynamic parameters in the path, please use {} to enclose the parameter names. For example, the /user/{userid} path declares the userid parameter in the path, which must be defined as a path-type input parameter. Query parameters do not need to be defined in the URL path.
Regular expression match is supported. Taking /user as an example of the path:
=/user: indicates exact match. When there are multiple APIs with /user, APIs configured with =/user have the highest matching priority.
/user/{id}: indicates that there is a dynamic parameter in the path. When there are multiple APIs with /user, APIs configured with a dynamic parameter have the third-highest matching priority.
/user: indicates access by exact match or prefix match. /user, /usertest, and /user/test/a all can access APIs with the path of /user.
Request Method: supports GET, POST, PUT, DELETE, and HEAD.
CORS is supported: configures cross-origin resource sharing (CORS). If enabled, Access-Control-Allow-Origin : * will be added to the response header by default.
Configuring frontend parameters
Input parameters: the input parameters include parameters from the header, query, and path, where a path parameter corresponds to a dynamic parameter defined in the URL path. For any parameter, the parameter name, parameter type, and parameter data type must be specified, and whether it is required, its default value, sample data, and description can be specified optionally. With these configuration items, API Gateway helps you with documentation and preliminary verification of input parameters.
Note:
If the request protocol is HTTPS, a request must carry SNI. To ensure request security, API Gateway will deny requests without SNI.
SNI (Server Name Indication) is an extension to TLS. It is used to address situations where a server has multiple domain names and is supported by the protocol since TLSv1.2. Previous SSL handshake messages didn't carry the destination address to be accessed by the client. If a server has multiple virtual hosts, each of which has a unique domain name and uses a unique certificate, then it will not be able to determine which certificate to return to the client. SNI addresses this issue by providing the host information in Client Hello.
Step 3. Configure VPC resources in the backend
The backend configuration of an API refers to the configuration that actually provides the service. API Gateway converts a frontend request based on the backend configuration and forwards the call to the actual service.
If your hosts and containers are implemented through the VPC, and you want to open up the service capabilities via API Gateway and private CLB, choose VPC resources in the backend.
1. Set Backend Type to VPC resources.
2. Select the desired VPC in the Backend Configuration step. Currently, API Gateway only supports connecting to VPC resources through private CLB.
3. Select the CLB instance of the backend domain name and the corresponding listener.
If you choose HTTP or HTTPS listener, please make sure that the backend CVM instance has enabled the public network bandwidth; otherwise, network request failure may occur (traffic generated by this policy is not included in the outbound traffic of the public network).
4. Enter http://vip+port or https://vip+port as the backend domain name. The requests sent to CLB will be HTTP requests or HTTPS requests depending on the content you enter. The VIP here is the VIP of the private network CLB instance, which can be viewed in its basic information (as shown in the screenshot in step 1).
5. Enter the backend path.
If you select the CLB listening type of HTTP/HTTPS, you must configure the backend path as the path configured in the CLB listener.
Domain name and path configured in the CLB listener:
The backend path in API Gateway must be consistent with that in CLB.
You also need to configure a parameter named host in Constant parameter and place it in the header. The value of this parameter is the domain name configured in the CLB listener.
If you select the CLB listening type of TCP/UDP, the backend path must be set to the path required by the business in the CVM mounted on the CLB.
If you configure host verification in the CVM, you need to configure a parameter named host in Constant parameter, and select the address to place parameter according to your own business, just like using a layer-7 listener. Subsequent configurations are the same as those of other APIs.
6. When the backend is connected to CLB, security groups on the real CVM instance should open the IP ranges of 100.64.0.0/10 and 9.0.0.0/8.
Step 4. Configure the response
API response configuration: includes the configuration of API response data and API error codes.
API response data configuration: indicates the type of returned data, including the data samples of successful and failed calls.
API error code definition: indicates the additional error code, error message, and description.
Note:
Currently, API Gateway directly passes through the response result to the requester without processing it. When SDK documentation is generated, the entered sample responses will also be displayed in the documentation, which will help users better understand the meanings of APIs.
Yes
No
Was this page helpful?