Schema type can be ambiguous. Do you exploit that?

(Kerrykimbrough) #1

Any place where your OpenAPI spec specifies a Schema Object, the schema need not define a “type” property. In which case the type of instances that can be validated is ambiguous. Any type of instance can be accepted, so long as it matches the schema keywords that apply. Indeed, if the instance type is X and the schema doesn’t define any X keywords, the instance is always accepted, no questions asked!

This seems like a risky design practice, because it makes the API contract much more complex. Any implementation that is not prepared to handle all possible valid instances could no longer rely on schema validation to screen out errors.

But here’s my question: Do you find such ambiguous type schema useful? Do you consciously exploit this feature of schema validation? Or do you consciously avoid ambiguous type schema?

I’m asking because I’m developing tools to automatically translate OpenAPI specs into test cases. Do these test cases need to verify all the possibilities allowed by an ambiguous type schema?

(Taylor Barnett) #2

Hey @kerrykimbrough,

I haven’t found a case where something like this would be useful. There might be some uncommon edge cases, but I would recommend avoiding them because as you said it is a risky design practice.

If you wanted to avoid something like this in your specs, you could write a Spectral rule to prevent it.

(Kerrykimbrough) #3

Thanks for your reply, Taylor