Lightweight Gateway API assembly commands and policies
Use the Lightweight Gateway assembly commands and policies in your API assembly to control the API's behavior.
The Lightweight Gateway uses a different set of API assembly commands and policies from the DataPower® API Gateway.
You cannot use an API with both gateway types, you cannot use commands or policies that are designed for one gateway type with the other gateway, and you cannot migrate APIs between gateways. When you develop APIs, you incorporate assembly commands and policies that are designed for that type of gateway. When you package an API in a product, the product specifies which type of gateway is used for processing the API.
Assembly commands determine how an API behaves. For this preview, Lightweight Gateway supports the following assembly commands.
execute command
The execute command provides a list of actions to be run, which can be
interrupted if a particular action throws an error. The execute command supports
the following policies:
invoke- Calls to a backend by using the provided
target_urlas its location. For this preview,invokesupports the following parameters:targetUrl- the URL for the target serviceverb- the HTTP method to use for the Invoke; the default value is KEEPtlsClientProfile- the TLS profile to use for the secure transmission of datainput- the name of a message that will be used to form the requestoutput- the name of a message that will be used to store the response data from the requesttimeout- the time (in seconds) to wait for a reply from the endpoint; the default value is 60
parse- Controls the parsing of a document. When the document is a JSON string, the string is parsed
instead of copied over. If input parsing is desired, use the message name
request; for the document that is returned from aninvoke, useresponseas the message name. For this preview,parsesupports the following parameters:input- the name of the inputmessagein the API contextoutput- the name of the outputmessagein the API contextdocumentType- the type of document being parsed in the API contextmaxDocumentSize- the maximum document size in bytesmaxDepth- the maximum level of nested label-value pairs, the maximum number of nested arrays, or the maximum number of combination of label-value pairs and arraysmaxWidth- the maximum number of properties on a JSON object or the maximum number of JSON items in a JSON arraymaxNameLength- the length of the label portion of the JSON label-value pairmaxValueLength- the length of a string valuemaxNumberLength- the maximum number length in bytes in the value portion of a JSON label-value pair when the value is a numbermaxUniqueNames- the number is for unique JSON labels
rateLimit- Applies one or more rate limits at any point in your API assembly flow. Rate limits restrict the
number of calls that are made to an API in a specified time period. Rate limits can also be
configured to limit calls to other resources, such as a backend server. For this preview,
rateLimitsupports the following parameters:name- a text label for the rate limitintervalUnit- the unit of time used to describe the interval: second, minute, hour, or dayintervalLen- the length of time (the number of units) during which the rate limit is appliedmax- the maximum number of calls allowed during the interval
set- Set the value of a runtime variable (including adding it) of a specified type by using the
specified name and value. For this preview,
setsupports the following parameters:variablename: string - name of variablevalue: string - value of the variable to write
messageBodymessageName: string - name of message to write value to.value: string - value of body to write.
messageHeadermessageName: string - name of message to write value to.headerName: string - header name within the message to write.value: string - value of header to write.
switch- Runs one of various sections of the assembly, based on which specified condition is fulfilled. A
switchcontains one or more ofcaseobjects; eachcasespecifies one or more conditions with corresponding actions for each condition. Cases are evaluated in order; after a case returns true, later cases are not evaluated at all.For this preview,
switchsupports the following parameters:casecondition- the condition that is being testedexecute- one or more actions to perform when the specified condition is met (see theexecutecommand for the list of supported actions)
throw- Throws an error when it is reached during an assembly flow, usually as a result of a condition
being met. For this preview,
throwsupports the following parameters:error- one of the following counted errors that are supported by thecatchcommand:BadRequestError: An error occurred while trying to access the request. This is not supported by the default catch; to catch this condition, specify it in your catch definition.ConnectionError: An error occurred while establishing a connection to another URL.LimitExceededError: The request exceeds the rate limit threshold that is specified in the API.
validate- Validates payload or parameters based on schemas that are located in the API.Note: For this preview, if you create your own API and use the
validatepolicy, the API must include the following configuration setting (which is also included in the sample demo.yaml API):x-ibm-configuration: compatibility: suppress-limitation-errors: trueFor this preview,
validatesupports the following parameters:modeopenapi-request- Validate requestbodyandparameters. Effectively the next 2 options at the same time.openapi-request-body- Validate requestbodyas defined by the operation object in the OpenAPI documentopenapi-request-parameters- Validate requestparameters(cookie, header, query parameters, and path) as defined in the path or operation object in the OpenAPI document.openapi-response-body- Validate the messagebodyas specified by the responses section of the API operation (none, default, or based on response status code)ref- Use a schema defined in the API's components/schemas section
input: Indicate which context to validate (request, message, response, and so on)error_response: Indicate whether a validation failure should result in 400 BAD REQUEST or 500 INTERNAL ERROR
catch command
The catch command specifies a list of supported error conditions and the actions
to be performed when one of those conditions is encountered by the execute
command.
The catch command is a list of objects, each of which has two fields:
errors and execute. The errors field can be any
combination of the supported errors to catch (3 currently). The execute field
contains a list of actions to perform when a specified error is encountered.
errors- Catches errors that occur during an API call. For this preview,
catchsupports the following errors:BadRequestError: An error occurred while trying to access the request. This is not supported by the default catch; to catch this condition, specify it in your catch definition.ConnectionError: An error occurred while establishing a connection to another URL.LimitExceededError: The request exceeds the rate limit threshold that is specified in the API.
execute- A list of actions to perform when one of the actions in the
executethrows an error that is listed in theerrorsfield. The actions that are supported by theexecuteparameter are the same actions that are supported by theexecutecommand.
finally command
The finally command specifies the final API actions to perform after all of the
actions in the main execute command and the catch command are
completed. The actions that are supported by finally are the same actions that are
supported by the execute command.