Validation
In the previous microlearning session, we covered how to configure a REST service. Now, we will focus on validating the data structure of incoming messages to ensure they meet the required format. This includes how to handle errors when validation fails and how to notify the client about these issues. By the end of this microlearning, you’ll understand how to implement validation for REST endpoints effectively
Should you have any questions, please get in touch with academy@emagiz.com.
1. Prerequisites
- Intermediate knowledge of the eMagiz platform
2. Key concepts
This microlearning centers around validating incoming messages when hosting a REST web service.
- With REST, we mean: A web service that adheres to the RESTful principles.
- With validation, we mean: Verifying whether the data structure we received is valid according to our definition.
- The external application pushes data to a REST web service (or API) hosted by eMagiz
- When doing so, the external application should adhere to the defined data structure
- If not, we need to refuse the call and respond with an error message
3. Validation
In the previous microlearning, we learned how to configure a REST service. In this microlearning, we will discuss how you can validate whether the party calling your REST endpoint is sending the correct information in terms of the structure of the message. We will also learn how you can subsequently report back to the client that a validation error occurred.
As you might know from SOAP web services implementation, the validation is automatically handled when the endpoint is called. This works differently for REST endpoints hosted by eMagiz. Therefore we need a little bit more elbow grease to get things going. Depending on your use of messaging or API Gateway, you might need to add an XML validating filter to your solution. For example, when hosting the REST web services in the all-entry of a messaging solution, you want to validate before placing it on your asynchronous onramp queue. You want to add an XML validating filter in the exit gate before calling the external system for a passthrough API GW. Note that when you select the option transformation for the API Gateway, eMagiz will do this automatically.
When adding or checking the XML validating filter, ensure that the checkbox (Throw an exception on rejection) is activated when the validation is done outside the all-entry.
As a result, the error handling will be triggered. In the case of an API Gateway solution, the error will automatically be given back to the previous step in the process. And since we advise validating the entry in case of messaging, we can send the message to the discard channel. Knowing that, we now need to follow that up. Since we need to give back the error to the client, the logical next step needs to happen in our all-entry. Here we need to make a distinction between validation errors and generic errors. We can do so by using an XPath router within the all-entry.
With the help of this configuration and a default output channel that leads to the generic setup (500 error), you can ensure that when an XML validating filter returns a validation error, you can define another HTTP status code and a different response body. You can use similar logic as with the generic setup for the 500 error. For specific information in setting that up please check out this [microlearning](intermediate-rest-webservice-connectivity-configuration.md).
Note that eMagiz will automatically create this setup when running an API Gateway solution. If you want to recreate the same experience in Messaging, please use the following XPath:
if (exists(err:xml-validation-exception)) then 'validation' else if (exists(err:exception[@class='org.springframework.integration.MessageTimeoutException'])) then 'timeout' else ''
4. Key takeaways
- External applications must follow the defined data structure when sending information to a REST web service (or API) hosted by eMagiz.
- If the incoming data does not meet the required structure, the request should be rejected, and an appropriate error message should be sent back to the client.
- eMagiz automatically handles much of the validation process when using the API Gateway, simplifying error management and reporting.
- For messaging flows, additional configuration is needed to replicate the same validation and error-handling functionality.
5. Suggested Additional Readings
If you are interested in this topic and want more information on it please read the help text provided by eMagiz when executing these actions and read the following links: