search

swagger-api / swagger-ui

Swagger UI is a collection of HTML, JavaScript, and CSS assets that dynamically generate beautiful documentation from a Swagger-compliant API.
https://swagger.io
Apache License 2.0
26.61k stars 8.97k forks source link

Issue with Combining oneOf and anyOf in the Same Object #10130

Closed renanligrande closed 2 months ago

renanligrande commented 2 months ago

Hello Swagger Team,

I'm encountering an issue while trying to define a schema that combines both oneOf and anyOf within the same object. The Swagger/OpenAPI specification seems to have trouble processing cases where these two validation keywords are used together in a single property, leading to ambiguous validation behavior.

Example Schema:

Below is an example of the schema I'm trying to use:

MyObject: type: object properties: field: oneOf:

The intention here is to allow field to be either a string or a number (using oneOf), while also allowing for the possibility of it being a boolean in some cases (with anyOf). However, the current validation rules in Swagger seem to be confused by the combination of oneOf and anyOf, and the object doesn't pass validation as expected.

Expected Behavior:

I expect the validation to work such that:

  1. field can be either a string or a number (but not both at the same time, handled by oneOf).

  2. field can also be a boolean (handled by anyOf), in addition to the options in oneOf.

Actual Behavior:

The current behavior results in validation errors, likely due to conflicts between oneOf and anyOf, as they seem to impose contradictory rules when used together.

Questions/Clarification Needed:

Is it possible to use oneOf and anyOf together within the same property in OpenAPI 3.0? If not, what would be the best way to structure this kind of logic?

Are there plans to support more complex combinations of these validation keywords in future versions of the OpenAPI specification?

Thank you for your help!

ponelat commented 2 months ago

Hi @renanligrande I don't think this works. A value cannot be a number, string or boolean at the same time. It has to be one of those only. E.g., 1 is a number, not a string and not a boolean.

However, there is always room for improvement to the way we show validation errors. In the schema, I don't see any which can be confusing. I'm going to close, as I don't see an issue with implementation yet. If you could provide a schema the examples that should validate against it, we can try help :)