Parameter | Required | Description |
API name | Yes | Name of the API you create, which must be unique within the current service and can contain up to 60 characters. |
Frontend type | Yes | Protocol for the client to access API Gateway. API Gateway supports two frontend types: HTTP&HTTPS and WS&WSS. |
URL path | Yes | You can write a valid URL path as needed. Configure a dynamic parameter in the path: Use {} to enclose the parameter name. For example, the /user/{userid} path declares the `userid` parameter in the path, which must be defined as a path-type input parameter. A query parameter does not need to be defined in the URL path. Regular expression match is supported for the path: Taking /user as an example of the path: =/user : Indicates exact match. When there are multiple APIs with /user , APIs configured with =/user will be matched first./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 will be matched first./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 | Yes | You can select GET, POST, PUT, DELETE, or HEAD. |
Authentication type | Yes | API authentication type. Multiple types are supported. |
CORS is supported | Yes | It is used to configure cross-origin resource sharing (CORS). After it is enabled, Access-Control-Allow-Origin : * will be added to the response header by default. |
Input parameter | No | 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. |
Parameter | Required | Description |
Action | Yes | COS API to be interconnected with API Gateway, which is linked with the request method in the frontend configuration. For more information, see Notes. |
Bucket | Yes | Only a bucket in the same region as API Gateway can be interconnected with. |
Calculate COS signature | Yes | After it is enabled, the COS signature will be calculated in API Gateway, so the system doesn't need to request the client to calculate the signature. |
Backend Path | Yes | It must start with "/". API Gateway will match objects in the bucket based on the path. |
Path Match Method | Yes | Full path match: Objects in the bucket are matched by the combination of the frontend path and backend path. This is suitable for scenarios where objects to be manipulated are at different paths passed in by the client. For the specific match rules, see Notes. Backend path match: An object in the bucket is matched by only the frontend path. This is suitable for scenarios where only a fixed object needs to be manipulated. No matter which path the client uses for access, the request will be always forwarded to the COS object at the backend path. |
Action
are as detailed below:Request Method Selected in Frontend Configuration | Action in Backend Configuration |
GET | GetObject |
PUT | PutObject |
POST | PostObject, AppendObject |
HEAD | HeadObject |
DELETE | DeleteObject |
Path | Case 1 | Case 2 | Case 3 | Case 4 |
Frontend path | / | /a | /a | /a |
Backend path | / | /b | / | /b |
Request path | /a/b | /a/b | /a/b | /a/c |
Passthrough path | /a/b | /b/b | /b | /b/c |
Was this page helpful?