As you have seen throughout this chapter, there are two data formats that we have been focusing on – XML and JSON. They are the most prominent in today’s API landscape. We have demonstrated the use of the map policy and how it can provide the need for custom transformations from one format to another. There may be times, however, when you just need to convert your JSON to an XML representation, or your XML to some standard JSON representation. Perhaps you are consuming JSON and want to log the payload, but your logging system requires XML, or vice versa. Or perhaps you have some XSLT that processes XML data, but the request is in JSON format. Whatever the case might be, there may be instances where you just need to transform XML to JSON or JSON to XML. For this purpose, API Connect provides two built-in policies, JSON to XML and XML to JSON. As you may have guessed, one transforms your JSON to an XML representation, and one transforms your XML data to a JSON representation.
Let’s first take a look at the JSON to XML policy. As its name implies, this policy expects a JSON input and will return XML. To use this policy, you will drag it onto the policy flow within the Gateway tab at the location in the flow where the JSON message is expected. In our example, we will want to transform our request JSON data to XML, so we drag it as the first policy just before our invoke action. Once this is done, you will see the configuration screen for this policy appear. You will notice that there aren’t many parameters here to define and you may just leave them all as the defaults. The configurable parameters are as follows:
- Title: The display title for this policy.
- Description: (optional): You can provide a description for this policy.
- Input: The APIC variable that will contain the JSON message to convert. As you have seen with the Redact policy example we discussed, message.body is the request message as it came into the API. This is also the default value for this field.
- Output: The APIC variable for storing the resulting output message. If the default input message is used, the default for this output variable will also be message.body.
- Conversion type: Defines how to format the output converted message. Your options here are Badgerfish or Relaxed Badgerfish. Badgerfish is the convention for translating an XML document into JSON. The Relaxed Badgerfish option can be used for more unconventional JSON elements as well as JSON to XML transformation. For our example, we will select the Relaxed Badgerfish option.
- Root XML Element Name: The root element of the XML document to be generated. This is only required if the incoming JSON has more than one top-level property.
- Always output the root element: A checkbox that would force the previously defined root element to always be outputted in the resultant XML. This is unchecked by default.
- Element name for JSON array elements: The XML element name to be used for each JSON array element.
For our example, we want to simply transform our input XML message to JSON. To accomplish this, we will leave the Input and Output fields blank so that the input request message sent to the API is used as the input to the transformation. For Conversion type, we selected Relaxed Badgerfish and checked the Always output the root element option, as shown in Figure 8.16:

Figure 8.16 – JSON to XML policy configuration
As we did in the Redact example, your final step will be to drag a parse policy before your json-to-xml policy, as you can see we did in Figure 8.13. Once you have finished your policy configuration, clicking Save and publishing your API will make it available to test. For our example, we will alter our JSON request for createOrder by making an array of items to demonstrate how the transformation converts arrays to XML. Figure 8.17 shows this request JSON and the converted response to XML, as performed by our JSON to XML policy:

Figure 8.17 – JSON to XML transformation
Notice in our example transformation message that the resulting JSON contains a top-level element named json. This is the result of selecting the Always output the root element checkbox in our policy configuration. Also notice that the transformation used the name json for this element, as we also specified in our configuration.
You can see how simple it is to transform your JSON to XML using the JSON to XML policy. If you thought it couldn’t get any simpler, you would be wrong! Let’s now take a look at XML to JSON. This policy configuration is very similar to the JSON to XML policy, with two small differences in the configuration. The first difference you will notice is that the XML to JSON policy has fewer parameters available. For this configuration, you only have the Title, Description, Input, Output, and Conversion type fields. The second small difference is the values available for the Conversion type field. For this configuration, you can choose badgerfish or apicv5. Selecting the badgerFish option will format your resulting JSON using the badgerfish convention, where selecting apicv5 will convert your XML to JSONx.
To accomplish this transformation, you first need to drag the policy onto Policy flow and complete the policy configuration. In our example, we will again be transforming the input message, so we will leave the Input and Output fields empty. We will then select the badgerFish option for our conversion type. Finally, we drag a Parse policy before our xml-to-json policy and we are finished. You can see our example configuration in Figure 8.18:

Figure 8.18 – XML to JSON policy
Once we have this configured, we can save and publish our API so that we can test it. Figure 8.19 shows our XML request and the transformed JSON response for this API:

Figure 8.19 – XML to JSON request and response
You have now seen how API Connect provides a simple drag and drop method for converting an XML message to a JSON representation, as well as for converting a JSON message to an XML representation using the built-in policies. This is yet another example of convenient solutions for very specific use cases. However, you will most likely find yourself in a situation where you need similar transformations to those discussed, but with more complexity or flexibility.
In the final section of this chapter, we will discuss how this can be accomplished using the two supported programming languages within API Connect.