OAS Validation on response keys - not values

[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]

Hi,

While technically a property name could be an empty string, because property names are strings and a string is a series of zero or more characters, it is not advised to do so. When trying to validate whether a payload matches an expected schema, it would be hard to look for a property if it has no name, unless the expectation is that there will be at least one property in the payload that has a name = empty string.

Can you describe the use case that you are trying to achieve? What conditions would are used such that a property name would be = empty string?

[alirz]

Thanks for your reply, i think my original post was confusing. 

I'm not interested in property name. What i'm looking for in OAS validator is to make sure that property is getting returned, with whatever value it can have including null. 

So if my OpenAPI Spec is 

properties:
  name:
    type: string

if the apigee returns name value as string or null. 

In OpenAPI, you can set the `nullable` property to indicate that a property's value can be null. However, this means you have to do that for all your properties. I was thinking the OAS Validator policy should have a setting that only checks for the existence of the property and doesn't care about its value.

[paul-wright]

OK, I think I am following this. Let me rephrase to confirm...

You are looking for Parameter validation on the Response message content, which is not currently supported. Parameter validation is currently supported on the Request message content only today. Per: https://cloud.google.com/apigee/docs/api-platform/reference/policies/oas-validation-policy#what-vali...

OR...

Is this related to the Message Bodies? Message body validation is based on the provided OAS schema. In both the Request and Response however, the <ValidateMessageBody> must equal true to enable body validation against the schema.

If neither of the above... could you provide examples of what you are looking for but not seeing? Please include:

• OASValidation policy configuration
• Example OAS Spec
• Example Request or Response that has the data that is not being checked as needed.

[alirz]

I want to do ValidateMessageBody on the returned JSON. But not the whole body just the json keys. Don't care about the values for each key. So in the openAPI spec that i have I would like just to make sure the properties are there, nothing more nothing else, but i don't care about the property type: integer, string, null, etc

[paul-wright]

Are you trying to avoid the overhead of checking the value types? Or looking for a way to define multiple value types for the same key?

[alirz]

I'm running into an issue where some values are null. I could technically update my OpenAPI spec YAML file to make them nullable. However, I figured this is a useful enough feature that there might already be an option for it. I need to send only an allowed list of properties, but their values don't really matter since they're sometimes null.

[paul-wright · Accepted solution]

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.

[paul-wright]

I forgot to add...

If you really need to do this outside of the OAS spec... you should be able to perform this type of inspection using the JavaScript callout. Then you could inspect the payload in basically any way you need to.

[alirz]

Thanks for your replies, yes i think javascript policy is the way to go for me right now