Create Microservice APIs

Last updated: 2020-05-06 10:13:27

    Operation scene

    This job guides you to create microservice API, through the API gateway console and explains the front-end and back-end configuration methods in detail.

    Operation step

    Create microservice API

    1. Login API Gateway console .
    2. In the list of services, click the service name of the target service to view the service.
    3. In the service information, click the * * manage API * * tab, and select * * General API * * or * * microservice API * * according to the backend business type. If the backend business is implemented in TSF, select [microservice API].
    4. Click [Create] for subsequent configuration.

    Front-end configuration

    1. Enter API name, and select the cluster name and namespace of the microservice connected to the front end.
    1. Choose microservice. API publishers can dock multiple microservice in one API.
      Make sure that the added services can be used by API gateway Access, including microservice deployed by cvm and microservice deployed by container (public network Access and NodePort Access).

    Currently, API gateway only supports transferring requests from repost to service instances of the same deployment type (virtual machine or container) of TSF. If a microservice instance with both virtual machine deployment and container deployment under the service, the API gateway is not supported as the request Entry.
    3. Enter URL path (Path).
    You can write the Valid URL path as needed. If you need to configure dynamic parameters in the path, use the {} Symbol and fill in the parameter name, such as /user/{userid} The path, which declares the userid parameter in the path, which needs to be defined as a Path type parameter in the input parameter. The Query parameter does not need to be defined in the URL path.
    4. Select the request method.
    The request method is HTTP method, and you can select GET, POST, PUT, DELETE, HEAD, ANY methods.
    5. Select the type of authentication: exempt from authentication or key pair.
    6. Choose whether or not to support CORS.
    7. Enter parameter configuration.

    Input Parameters Contains parameters from Header, Query, and Path. The Path parameter corresponds to the dynamic parameter defined in the URL path.
    Any parameter needs to specify the parameter name, parameter type, and parameter data type, and you can indicate whether it is required, default value, sample data, and description. With these configurations, the API gateway can assist you with the documentation and preliminary verification of the input parameters.
    Two required parameters, X-NameSpace-Code and X-MicroService-Name, need to be passed in the call. These two parameters control which microservice the request of the API gateway is sent to, and can be placed in Header, Path, and Query. If it is placed in Path, it is similar to the general API. You need to configure path parameters in the path, such as /{X-NameSpace-Code}/{X-MicroService-Name} If the variable XripNameSpaceCodemark crgtmeme XripMicroServiceMainNameSpace coupon activity, then the URL of Access is https://access_domain_name/crgt/coupon-activity/ . Except for these two fixed parameters. The configuration of other parameters is the same as that of the generic API.

    • The X-NameSpace-Code path parameter is the code value configured by the namespace selected in the configuration in the Tencent microservice platform namespace.
    • The X-MicroService-Name path parameter is the microservice name configured in the service governance of Tencent microservice platform for the cluster selected in the configuration.
    1. Click "next" to configure the backend.

    Backend configuration

    1. Configure the backend path.
      Specific backend service request path. If you need to configure dynamic parameters in the path, use the {} Symbol and fill in the parameter name, which will be used to configure the input parameter from the front-end configuration in the configuration of the parameter mapping. The path here can be different from the front end, do path mapping. The request path for the real service.
    2. Sets the backend timeout.
      The timeout from the API gateway initiation to the back-end service invocation. The maximum time-out limit is 30 seconds. When the API gateway calls the backend service and does not get a response within the timeout, the API gateway will terminate the call and return the corresponding error message.
    3. Choose Cloud Load Balancer's way.
    4. Set Session to keep.
    5. Set Parameters.
    • Backend parameters: X-NameSpace-Code and X-MicroService-Name are fixed parameters and cannot be mapped. Other parameters configured by users can be mapped.
      If your Body parameters are only in form format, you can map them directly when the front and rear parameters are configured. If it is in JSON format, the JSON parameter API gateway will directly pass through.
    • Mapping parameters: parameter mapping is used to map the input parameters of the front end to the parameters of the actual backend service. The default mapping parameter maps the input parameter with the same name and parameter location. At the same time, you can change the mapping method of parameters according to your requirements, such as mapping the input parameters from Path to Query parameters in the backend service.
    • Constant parameters: you can add self-defined constant parameters as needed. Constant parameters remain the same in each API call. At the same time, you can use the system parameters to pass some of the system information you need to the back-end service.
    1. Click "next" to configure the response result.

    Response Result

    API response configuration includes API response data configuration and API error code configuration. The response result configuration is used only for generating documents.
    API response data configuration, which is used to indicate the data type returned, including data examples of successful calls and failed calls.
    API's error code definition, which is used to indicate additional error codes, error messages and descriptions.


    When passing through the API gateway Access backend microservice, Open to Internet needs to correspond to the security group of the virtual machine where the backend service resides. Users can set the source of security group Access, Protocol port and Access policy.
    When you set the source of Access, you need at least IP range and, where Open to Internet's API gateway is located, and other sources are determined according to customer needs.

    • For applications deployed by virtual machines, the corresponding service port on Open to Internet's virtual machine is required. For applications deployed on the container, Open to Internet needs the service port of the virtual machine where the container resides, not the nodeport port.
    • For container applications, IP drift often occurs. It is recommended that all the machines in the cluster run on the service port of Open that runs on the container.

    Was this page helpful?

    Was this page helpful?

    • Not at all
    • Not very helpful
    • Somewhat helpful
    • Very helpful
    • Extremely helpful
    Send Feedback