The response body sent to the Client by API Gateway contains many fields. If you want to modify the content of the response body, you can do so via custom response body plugin.
The custom response body plugin applies during the response process, and the response content rewriting service can be deployed in SCF, on the public network, or in a VPC. The service backend will send the response body to API Gateway after processing the request message. API Gateway will forward the response content to the response body modification service after receiving it. The modification service will send the modified content of the response body to API Gateway after modifying it. Then, API Gateway will forward the modified response body to the service backend.
2. On the left sidebar, click Plugin > Custom Plugin to enter the custom plugin list page.
3. Click Create in the top-left corner of the page to create a custom response body plugin.
For verification services deployed in SCF, you need to enter the following data when creating the custom response plugin:
Parameter
Required
Description
Function
Yes
Select the namespace, name, and version of the response body modification function.
Backend timeout
Yes
Set the backend timeout that API Gateway forwards the request to the function that is used to modify the response body. The maximum time limit is 30 minutes. When no response is returned before the timeout after API Gateway calls the function, API Gateway will end the call and return an error message.
Custom content
Yes
Set the response content sent by API Gateway to the function used to modify the response body. You can select Header, Body, and Query. The response content not selected will not be modified and will be forwarded to the client as is.
Base64 Encoding
Yes
Specify whether to Base64-encode the response content to be forwarded by the service backend to the function. Generally, it is applicable to binary content.
For verification services deployed on the public network, you need to enter the following data when creating the custom response plugin:
Parameter
Required
Description
Request method
Yes
Request method of the custom response body function, which can be GET, POST, PUT, DELETE, HEAD, and ANY.
Public network service
Yes
Access address of the custom response body rewriting service, which can be an HTTP or HTTPS address.
Path match mode
Yes
It can be backend path or full path match.
Backend path match: The configured path is used to request the service.
Full path match: The overlapping part is used to request the service. For example, if the configured API path is `/a/` and the request path is `/a/b`, then the path transferred to the service will be `/b` after full path match is enabled.
For verification services deployed in a VPC, you need to enter the following data when creating the custom response plugin:
Parameter
Required
Description
VPC
Yes
Select the VPC of the response body rewriting service.
Request method
Yes
Request method of the response body rewriting function, which can be GET, POST, PUT, DELETE, HEAD, and ANY.
Backend address
Yes
Access address of the response body rewriting service, which can be an HTTP or HTTPS address.
Step 3: binding the API
1. Select the plugin created in step 2 from the plugin list. Click Bind API in the Operation column.
2. In the Bind API pop-up window, select the service, environment, and the API that needs to be bound to the plugin.
3. Click OK to bind the plugin to the API. At this time, the configuration of the plugin has taken effect for the API.
pluginData
{
"endpoint_timeout":15,// Backend timeout period in seconds. Value range: 0–60
"is_base64_encoded":true,// Whether to Base64-encode the response content to be forwarded by the service backend to the SCF
"is_custom_status":true,// Whether to send the response status code content to the SCF
"is_custom_headers":true,// Whether to send the response Header content to the SCF
"is_custom_body":true,// Whether to send the response Body content to the SCF
"user_id":1253970226// appid
}
Notes
Binding a custom plugin to the API means creating a trigger for the function to trigger the API. Deleting the trigger on the SCF side means unbinding the plugin from the API.
Currently, the custom response body plugin supports only event-triggered functions but not HTTP-triggered functions.
The priority of the custom response body plugin is lower than that of all plugins applied during the request process.
If the custom response body plugin is bound to an API with a Mock or TSF backend, it will not take effect.
The custom response body plugin does not support the HTTP2 protocol.
The custom response body plugin does not support the response body compressed in the gzip format returned by the backend.
Yes
No
Was this page helpful?