Solved: OAS Validation on response keys - not values - Page 2

alirz

How can i use the message body of response with OASValidation but don't care about null or undefined values.

For instance if in my spec i have

properties:
  name:
    type: string

If my backend returns a name as undefined, the OAS validator doesn't like it. One solution is to add nullable true to the spec. However, I was wondering if there's a way to have the validator only check for the existence of the keys (in this case name), not its value.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OASValidation continueOnError="false" enabled="true" name="OAS-Response-Validation">
    <DisplayName>OAS-Response-Validation</DisplayName>
    <Options>
        <ValidateMessageBody>true</ValidateMessageBody>
    </Options>
    <Source>response</Source>
    <OASResource>oas://apispec.yaml</OASResource>
</OASValidation>

paul-wright

OK, I see.

Looking down this path, it starts to beg the question on what types of customization should be allowed on top of what is specified in the spec itself. For instance today, you can optionally configure the behavior of the policy when header, query, or cookie parameters are present in the request that are not defined in the OpenAPI Specification by using the <AllowUnspecifiedParameters> tag.

However, I think this is a slippery slope. The spec is there to give you control on what and what not to look for. For instance, if we had a flag that allowed nulls for values... it would probably have to do that for all values, at which point it may be performing a kind of schema structure check, but would allow a basically empty payload to pass through.

The OAS spec allows you to make the choices, to have the control, to determine which fields, parameters, properties, should exist, have a specific value type, etc.

I think in the long run, specifying which fields can accept nulls is the way to go for the use case you have described.

View solution in original post