Digital Experience

DataPower’s handling of RESTful services via JSON

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

  1. Incoming JSON payload is validated as a well-formed JSON document.
    • Simultaneously JSON parser enforces limits on the incoming JSON document
  1. 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.
  1. The JSON message is now available in two context forms:
  • INPUT context (original message) input
  • _JSONASJSONX context (the converted JSONx message that can be manipulated with XSLT, just as any other XML)jsonasjsonx

 

Before firmware version 6.0, DataPower offered the following process of dealing with JSON payloads thru converted JSONx:

JSONxHandling

 JSONtoJSONx

 Source: for further examples visit here.

ValidateJSONx

 

 

 

JSONx data, _JSONASJSONX context, now can be validated using jsonx.xsd schema file in the store:// directory.

 

 

 

JSONx2SOAP

 

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.

SOAP2JSONx

 

IBM / Red Hat - Unlock Potential App Modernization
Unlock Your Potential with Application Modernization

Application modernization is a growing area of focus for enterprises. If you’re considering this path to cloud adoption, this guide explores considerations for the best approach – cloud native or legacy migration – and more.

Get the Guide

 

 

 

 

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.

jsonx2json

 

 

 

 

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

 clientSpecificJSV

         Source: JSON schema validation explained here.

     2.   Manipulated with a transform action that uses a processing control file such as:

JSONiq

JSONiqProcessingControl

 

 

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)

GatewayScriptTransformation

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.

SourceSee the parser limits Here: JSON 


About the Author

More from this Author

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to the Weekly Blog Digest:

Sign Up