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:
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: