In the IBM DataPower world, JSON is the representational format used by the RESTful façade exposed by the appliance. Starting with firmware version 3.8, there has been a gradual increase in the number of ways that JSON payload is handled.
DataPower services that will handle and process JSON messages include:
- Multi-Protocol Gateway (MPGW)
- XML Firewall
- Web Token Services (Firmware v7.0 & up)
These services offer additional options to a developer on what type of request or response to expect. Selection of type of payload results in sort of treatment the payload is to receive. Our main concern in this article is JSON payload and its processing and manipulation. So, let’s dive in:
Non-XML as the request/response type
The original JSON message is available as the INPUT context.
JSON as the Request / Response Type
- Incoming JSON payload is validated as a well-formed JSON document.
- Simultaneously JSON parser enforces limits on the incoming JSON document
- Message is converted to JSONx (an IBM standard to represent JSON as XML).
- Simultaneously XML parser enforces limits on JSONx document as it is being created.
- The JSON message is now available in two context forms:
- INPUT context (original message)
- _JSONASJSONX context (the converted JSONx message that can be manipulated with XSLT, just as any other XML)
Before firmware version 6.0, DataPower offered the following process of dealing with JSON payloads thru converted JSONx:
Source: for further examples visit here.
JSONx data, _JSONASJSONX context, now can be validated using jsonx.xsd schema file in the store:// directory.
Using an explicit Transform action with a custom XSLT style sheet, JSONx message will now need to be transformed to desired data format that is expected by the back end.
Response from the backend will need to be converted to JSONx using a customer XSLT in a transform action, if client expects a JSON response.
The appliance provides jsonx2json.xsl style sheet in the store:// directory that can be used to convert JSONx to JSON by applying an explicit transformation action to the desired context.
Starting with firmware v6.0 & later, in addition to the above capability, now available INPUT context, the original JSON payload could be processed in 3 different ways:
1. Validate JSON schema
Source: JSON schema validation explained here.
2. Manipulated with a transform action that uses a processing control file such as:
XQuery transformation with JSONiq to:
- Text
- XML
- another JSON
- etc.
Source: see JSON transformation to different data types here.
3. Manipulated using a GatewayScript (firmware v7.0 & up)
Source: More about GatewayScript here.
Considering Parser limitations for JSON payloads
JSON parser settings and XML parser settings work together to provide configurable settings for message size, nesting depth, and other limits.
- JSON parser settings apply to the JSON message
- XML parser settings apply to XML and converted JSONx messages
The parser limits helps protect against a denial-of-service (DoS) attack when a single maliciously huge message is sent to the service to keep it busy.
Default limits are applied unless Setting Configurations are specified. The maximum message size limit applies to JSON, SOAP, XML, and non-XML message types.
- Limits are not enforced for pass-through message type.
More restrictive limits of both the JSON and XML parser are enforced. Exceeding either parser limit results in an HTTP 500 response code being returned to the client.
Source: See the parser limits Here: JSON
