Handling Unexpected Parameters in Web or REST Consume Service
When you add an operation for a web or REST consume service you can select which parameters you expect. But how do you handle unexpected parameters? By ‘unexpected I mean that if I have two parameters of ‘type’ and ‘date’ but someone sends a request with a parameter of ‘type123’ or ‘datesz’ then that is ‘unexpected’. And I want to respond to the user with something helpful about their typo/incorrect param. You can’t create a parameter for every variation of a misspelling of an expected param in the ‘Operation’ form. And so it seems the only way to capture unexpected params would be in the microflow itself. Has anyone ever handled unexpected parameters in a different way? And if not how have you handled them within a microflow? And/or does anyone know if MX will update this form to include something like the image below to provide options on how to handle them?
This is generally not how REST services work. If the URL contains a query parameter that the REST service doesn’t implement, it ignores it.
Why would you want to deviate from this default behavior?
What if you made all your parameters strings? Then in your rest service operation, you can take the parameters that arent supposed to be strings and convert them to the appropriate type. You could also use your import mapping to convert the strings to the right data type. The import mapping has a feature called “Convert using” where you can use a microflow to convert the value to what you need it to be.