You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The request here is to make all nullable fields in resource creation endpoints non-required.
Whenever fields are marked both as required and as {type} or null in creation endpoints, the field has to be explicitly included in the payload and set to null. If the field is omitted, a validation error is given.
For example, voorkeursDigitaalAdres in partijenCreate is defined in this way (required, but also accepts null in lieu of an object):
If a field is nullable, then null is a sane default value that the API can set for the client, without having to explicate the fields in the payload.
Toegevoegde waarde / Added value
The current behavior is undesirable because it makes constructing requests very verbose and generally raises the friction of building a valid request. This is especially visible in tests, where the current approach leads to the need for a lot of factories and fixtures. I would say providing sane defaults wherever possible makes for a better developer experience.
Aanvullende opmerkingen / Additional context
No response
The text was updated successfully, but these errors were encountered:
Discussed this with @danielmursa-dev . To clarify: the issue here specifically refers to creation endpoints. This in contrast to PUT where, if an optional field is absent, you have two possible behaviors:
Interpret the missing optional field as "reset to None"
Interpret the missing optional field as "keep the existing value"
The default DRF behavior seems to be 2. Personally, I think this is not correct behavior: PUT effectively means "replace the resource's state to the provider body", which I think further means optional fields would behave as they would with a POST (PUT should also be idempotent, which it would not be if other clients could PATCH the optional field in the meantime`).
But that's a discussion for another day: for now, we agreed to keep the existing behavior (2) and only default to None in creation endpoints.
Thema / Theme
Klantinteracties API
Omschrijving / Description
The request here is to make all nullable fields in resource creation endpoints non-required.
Whenever fields are marked both as
required
and as{type} or null
in creation endpoints, the field has to be explicitly included in the payload and set tonull
. If the field is omitted, a validation error is given.For example,
voorkeursDigitaalAdres
inpartijenCreate
is defined in this way (required
, but also acceptsnull
in lieu of anobject
):Omitting the field from a create payload yields:
Which is fixed by adding:
If a field is nullable, then
null
is a sane default value that the API can set for the client, without having to explicate the fields in the payload.Toegevoegde waarde / Added value
The current behavior is undesirable because it makes constructing requests very verbose and generally raises the friction of building a valid request. This is especially visible in tests, where the current approach leads to the need for a lot of factories and fixtures. I would say providing sane defaults wherever possible makes for a better developer experience.
Aanvullende opmerkingen / Additional context
No response
The text was updated successfully, but these errors were encountered: