Proposal for Required Fields

[tfranzel]

spectacular apparently is used by a few people now. i'd like to get some feedback on an idea before doing potentially invasive schema changes.

Theoretically we could make all read-only fields required. Which is imho a better representation of what DRF is actually doing. afaik DRF will always render a field even if it is null. so it is indeed required and not optional. note that this would only apply to responses and not requests.

It is an easy change, but i would like to get feedback beforehand. i don't want to break your schemas/clients. For our purposes it looks very good and the generated clients also honor it well.

i will create a pull request for you to check this out.

[tfranzel]

@MissiaL @tsouvarev @jayvdb you guys certainly exposed spectacular to a few code bases. what do you think?

[tsouvarev]

Sounds good to me

[MissiaL]

For me too. I will test you changes

[tfranzel]

awesome! i merged it. lets see where it takes us. thanks for checking it out.

[MissiaL]

I checked changes
So I see that changes are broken my scheme

This creates problems.
The drf_yasg does not do this and maybe it will also break the scheme for future users

We use the request validator https://github.com/p1c2u/openapi-core and now it swears at these required fields

[tfranzel]

@MissiaL i just remembered why this is problematic. for us it is primarily a code generator issue. do you use the schema for code generation or only for display?

https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.3.md#fixed-fields-20

If the property is marked as readOnly being true and is in the required list, the required will take effect on the response only.

so strictly speaking validation should not complain about that afais. the spec also states that the written word overrules the json schema specification.

for us it is mainly a typescript generation issue which i encoutered just now.

[tfranzel]

@MissiaL i'm on the fence on reverting this.

• could you elaborate on your openapi-core validation issue?
• do you use the schema in any code generators?

i would like to make a more informed decision on how to proceed.

[MissiaL]

The problem was in our versioning
Some fields should be absent in the schema, but this does not work in the schema generator
#56

[tfranzel]

@MissiaL with the fix i proposed in #56, is this issue resolved?

[MissiaL]

I have not tested this implementation yet. I will study and inform here soon