While working to handle exceptions with the new OASValidation policy in Apigee I have found a few inconsistencies in the faultString generated whenever the validation fails.
For example when the user enters a query parameter that is not accepted by the path, it generates the following faultString:
"faultstring": "OASValidation OpenAPI-Spec-Validation with resource \"oas://MyOAS.yaml\": failed with reason: \"[IGNORE - Query parameter 'fake' is unexpected on path \"/rigs\": [], ERROR - query parameter is unexpected : fake: []]\"",
Note that the query parameter for which the validation has failed is mentioned in the faultString.
We can therefore use this information to generate an error payload like:
{
"code": "1",
"title": "Query parameter is not valid",
"detail": "Invalid Query Parameter: fake"
}
However the issue arises in cases where the faultString messages are inconsistent and do not contain the name of the query parameter that fail the validation.
For example, if a user passes an invalid data type for page-number parameter (expected: integer, given: string), the following faultString is generated:
"faultstring": "OASValidation OpenAPI-Spec-Validation with resource \"oas://MyOAS.yaml\": failed with reason: \"[ERROR - Instance type (string) does not match any allowed primitive type (allowed: [\"integer\"]): []]\"",
Note how the above faultString does not contain the name of the parameter for which the validation fails.
Hence we are unable to generate the required error payload:
{
"code": "1",
"title": "Parameter data type is not valid",
"detail": "Invalid data type for: page-size"
}
There are other cases as well where I see this issue, namely when user passes an integer value beyond the mentioned range OR when user passes a value that is not mentioned in the enum.
As per my understanding, this is an incorrect behavior from the policy
But for the time being, can someone please suggest a solution or a work around for this?
NOTE: I'm using Edge Private cloud version 4.51.00
LinkedIn
Twitter
