Handling non-JSON data in a REST API
REST APIs are set up by default to handle JSON data, but can also handle other data formats.
Before you begin
About this task
When a message arrives on the Input node of a subflow for an implemented operation, the message domain of that message is set to JSON. You can handle other types of data in a subflow for an implemented operation by using a ResetContentDescriptor node to change the message domain of the message before any message parsing is performed.
You can also use a Route node to handle multiple types of data in the same subflow. You can configure the Route node to route data to a ResetContentDescriptor node based on the Content-Type header in the request message. The Content-Type header can be added to the request by the HTTP client, and is used to describe the type of the data in the request.
To handle non-JSON data in a REST API, complete the following steps:
- Open the REST API Description, for the implemented operation that you want to modify, click the Open the Operation link.
If you want to handle multiple types of data in this subflow, complete the following steps:
- Add a Route node to the canvas.
- Connect the Out terminal of the subflow Input node to the In terminal of the Route node.
- Add Output terminals to the Route node for each message domain and type of data that you want to process by right-clicking the Route node and clicking Add Output Terminal.
- Route to the new terminals on the Route node by adding entries to the Filter table.
To route on Content-Type, use the following XPath expression as an example for handling XML request messages by using the XMLNSC domain:
Use the starts-with function in your XPath expression because HTTP clients might send in an optional character set parameter following the type and subtype.
Add a ResetContentDescriptor node to the canvas.
- If you added a Route node in the previous step, you must add a ResetContentDescriptor node for each message domain and type of data that you want to process. If you are processing JSON data, you do not require a ResetContentDescriptor node.
- If you did not add a Route node in the previous step, connect the Out terminal of the subflow Input node to the In terminal of the ResetContentDescriptor node.
- If you added a Route node in the previous step, then connect the terminal that you added in the previous step to the corresponding ResetContentDescriptor node for that message domain and type of data.
- For each ResetContentDescriptor node that you added in the previous step, configure the ResetContentDescriptor node by specifying the value of the Message domain property. You must also select Reset message domain.
- You can now continue to implement the operation by using any of the standard message flow nodes that are included in IBM Integration Bus. Connect any new message flow nodes to the Out terminal of the IBM Integration Bus nodes that you added in the previous steps.
What to do next
- Implement error handling for the REST API as a set of subflows, see Implementing an error handler in a REST API.
- Secure your REST API by using HTTPS for encrypting communications between the client and server, see Securing a REST API by using HTTPS.
- Secure your REST API by authenticating users with HTTP Basic Authentication, see Securing a REST API by using HTTP Basic Authentication.
- If your REST API is going to be used by client-side code that is running in a web browser, you might have to configure Cross-Origin Resource Sharing, see Permitting web browsers to access a REST API by using Cross-Origin Resource Sharing.