When you have an allOf JSON schema of two objects with the unevaluatedProperties property, let's say:
{
"type": "object",
"unevaluatedProperties" : false,
"allOf": [
{
"type": "object",
"properties": {
"hello" : {
"type" : "string"
}
},
"required" : ["hello"]
},
{
"type": "object",
"properties": {
"world": {
"type" : "string"
}
},
"required" : ["world"]
}
]
}
The validator should treat the validation equivalently to:
{
"type": "object",
"properties": {
"hello" : {
"type" : "string"
},
"world": {
"type" : "string"
}
},
"additionalProperties" : false,
"required" : ["hello","world"]
}
Yet, if redocly generates the OpenAPI Spec, it says that the object may have additional properties, which is precisely forbidden in that case.
I suppose that the unevaluatedProperties thing is from a more recent draft, but it has been introduced for a reason and makes the usage of the very core allOf feature much more efficient, as it effectively allows you to reuse object schemas defined throughout the project in a much stricter way.
Not sure if this is a bug or a feature that has not yet been introduced ? Being able to use the unevaluatedProperties property is precisely what would provide a solution for the edge-case you mention in your docs. This would thus effectively eliminate a limitation of the usage of allOf for a much better and stricter reusability of your joined object schemas. Currently, we have to rewrite object schemas multiple times if they differ by only one property due to the corresponding problem mentioned in your docs. In many cases, it is very essential to e.g. validate that an API response does or precisely does not provide an additional property in the returned data.
So may I suggest the introduction of the following feature:
If redocly detects the usage of unevaluatedProperties: false in an allOf schema of multiple objects, redocly should remove the unevaluatedProperties: false property from that schema and add a top-level additionalProperties: false property to the generated schema. That would even transform that schema into one that is compatible with validators from earlier drafts too. That would be extremely helpful, and would make the use of allOf to avoid the need of redefining object schemas, as you also mention, much more precise and efficient.
When you have an
allOfJSON schema of two objects with the unevaluatedProperties property, let's say:The validator should treat the validation equivalently to:
Yet, if redocly generates the OpenAPI Spec, it says that the object may have additional properties, which is precisely forbidden in that case.
I suppose that the
unevaluatedPropertiesthing is from a more recent draft, but it has been introduced for a reason and makes the usage of the very coreallOffeature much more efficient, as it effectively allows you to reuse object schemas defined throughout the project in a much stricter way.Not sure if this is a bug or a feature that has not yet been introduced ? Being able to use the
unevaluatedPropertiesproperty is precisely what would provide a solution for the edge-case you mention in your docs. This would thus effectively eliminate a limitation of the usage ofallOffor a much better and stricter reusability of your joined object schemas. Currently, we have to rewrite object schemas multiple times if they differ by only one property due to the corresponding problem mentioned in your docs. In many cases, it is very essential to e.g. validate that an API response does or precisely does not provide an additional property in the returned data.So may I suggest the introduction of the following feature:
If redocly detects the usage of
unevaluatedProperties: falsein anallOfschema of multiple objects, redocly should remove theunevaluatedProperties: falseproperty from that schema and add a top-leveladditionalProperties: falseproperty to the generated schema. That would even transform that schema into one that is compatible with validators from earlier drafts too. That would be extremely helpful, and would make the use ofallOfto avoid the need of redefining object schemas, as you also mention, much more precise and efficient.