Repository navigation
Allow "required" list to have undefined properties #97
Description
I think requiring property names listed in required to be defined in properties is too strict. I also couldn't find this requirement in the JSON Schema or OpenAPI specs. JSON Schema validators and the Swagger Editor are fine with property names listed in required that are not defined in properties.
It makes sense to list required properties without defining them in properties when using allOf where one sub-schema requires some properties but does not specify them while another sub-schema only provides the specifications of the properties (possibly even without stating which ones are required and which ones aren't). This is especially useful when referencing and merging schema definitions or when expressing discriminated unions with some properties that are common to all union members.
I suggest to remove the following code block
and the require_properties argument:
I have seen the test case
but it also seems to be valid to express this schema like this:
{
'Credit': {
'type': 'object',
'properties': {
'clientId': {'type': 'string'},
}
},
'CreditCreate': {
'type': 'object',
'required': ['clientId'],
'allOf': [
{
'$ref': '#/components/schemas/Credit'
},
# possibly more schemas to merge ...
]
}
}Or did I miss this rule somewhere in the spec?
Activity
edermaxc commentedon Jul 21, 2021
Hi Guys, did any one figure out a workaround for this problem changing the spec?
feat: handle allof when required linked to parent object (python-open…
hibougeek commentedon Jun 16, 2022
@p1c2u I did a pull request to solve this issue (#154) . Could you review it please ? We are currently blocked on our side, it will helpful to have a status on it.
Marwen94 commentedon Jun 16, 2022
Thanks @hibougeek ! We are blocked by this also.
Merge pull request #154 from hibougeek/feat/#97_handle_required_in_allof
tembleking commentedon May 7, 2025
The problem with #312 is that it left the validation in an inconsistent state: if the schema contains
allOfthen it will still try to validate that the fields are present in the inner referenced components.This is what's causing #390 and what I tried to fix in #391.
So either we never validate the presence of inner
propertiesdefined in therequired, or we always check them.I'd rather try to validate that required are always defined in properties, even if the OpenAPI spec does not enforce it, because if you define a field in
requiredbut do not define it underproperties, and the request body doesn't include that field, it will still be considered invalid. The presence of the field is enforced by therequiredlist.Example:
In this case,
foois required, even though it is not defined under properties. Iffoois missing in the request body, validation will fail. If it is present, it will accept any value, because its schema is{}by default (i.e., no constraints).To avoid ambiguity, it's best practice to define all
requiredfields explicitly inproperties: