._tyk_context.KEYNAME
namespace._tyk_meta.KEYNAME
namespace._tyk_context.request_data
namespace where it will be available in as a key:[]value
map{{ index ._tyk_context.request_data.variablename 0 }}
in a template will expose the first entry in the request_data.variablename
key/value array.
_tyk_context
and _tyk_meta
respectively.jsonMarshal
performs JSON style character escaping on an XML field and, for complex objects, serialises them to a JSON string (example)xmlMarshal
performs the equivalent conversion from JSON to XML (example)operationId
defined in the OpenAPI Document that declares both the path and method for which the middleware should be added. Endpoint paths
entries (and the associated operationId
) can contain wildcards in the form of any string bracketed by curly braces, for example /status/{code}
. These wildcards are so they are human readable and do not translate to variable names. Under the hood, a wildcard translates to the “match everything” regex of: (.*)
.
The request body transformation middleware (transformRequestBody
) can be added to the operations
section of the Tyk OAS Extension (x-tyk-api-gateway
) in your Tyk OAS API Definition for the appropriate operationId
(as configured in the paths
section of your OpenAPI Document).
The transformRequestBody
object has the following configuration:
enabled
: enable the middleware for the endpoint
format
: the format of input data the parser should expect (either xml
or json
)
body
: [see note] this is a base64
encoded representation of your template
path
: [see note] this is the path to the text file containing the template
body
or path
to indicate whether you are embedding the template within the middleware or storing it in a text file. The middleware will automatically select the correct source based on which of these fields you complete. If both are provided, then body
will take precedence and path
will be ignored.PUT /anything
endpoint. The body
contains a base64 encoded Go template (which you can check by pasting the value into a service such as base64decode.org).
Decoded, this template is:
PUT /anything?param=foo
as follows:
/anything
endpoint returns the details of the request that was received by httpbin.org. You can see that Tyk has swapped value1
and value2
and embedded the X-Header
header and param
query values into the body of the request.
The configuration above is a complete and valid Tyk OAS API Definition that you can import into Tyk to try out the mock response middleware.
path
in the transformRequestBody
object), remember that Tyk will load and evaluate the template when the Gateway starts up. If you modify the template, you will need to restart Tyk in order for the changes to take effect.transform
object to the extended_paths
section of your API definition.
The transform
object has the following configuration:
path
: the path to match onmethod
: this method to match ontemplate_data
: details of the Go template to be applied for the transformation of the request bodytemplate_data
object by the following fields:
input_type
: the format of input data the parser should expect (either xml
or json
)enable_session
: set this to true
to make session metadata available to the transform templatetemplate_mode
: instructs the middleware to look for the template either in a file
or in a base64 encoded blob
; the actual file location (or base64 encoded template) is provided in template_source
template_source
: if template_mode
is set to file
, this will be the path to the text file containing the template; if template_mode
is set to blob
, this will be a base64
encoded representation of your templatefile
at location ./templates/transform_test.tmpl
. The input (pre-transformation) request payload will be json
format and session metadata will be available for use in the transformation.
REQUEST
tab, then select your input type, and then add the template you would like to use to the Template input box.
transform
object to the extended_paths
section of your API definition.
In the example below the Request Body middleware (transform
) has been configured for HTTP POST
requests to the /anything
endpoint. The Request Body Transform middleware is directed to use the template located in the blob included in the template_source
field. The input (pre-transformation) request payload will be json format and session metadata will be available for use in the transformation.