-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consistent empty / null fields #258
Comments
@Dragomir-Ivanov, FYI. What do you think? |
@smyrman I think we need to consider also |
Good ponits @Dragomir-Ivanov. If files are omitted on When fetching the resource back out, they will be either omitted or |
PS! we might need to make sure that PATCH results always serialize (the original) resource before calculating changes / base. |
Proposal overview
Only some storage backends (such as MongoDB) would be able to really make the distinction between
null
and omitted values on top level fields. SQL storage backends would already treat the values equally, no matter what we do in code.This is a proposal to treat
null
values and omitted values equally in code, and configure on the resource how all empty fields should be rendered; either asnull
, or omitted. The change apply specifically to theresource.Schema
type (includingresource.Object
filed validator). It does not apply to field validators such asresource.Dict
.Motivation
This allows for more consistent APIs to be written that is easier to use in e.g. TypeScript. It also allows removing top-level fields via PATCH requests without deferring to JSON-PATCH syntax. This can be simpler to do for some clients.
Changes
Suggested changes include:
Required
field in favor of aNullable
field on Schema.Nullable: true
as"oneOf": [{..}, {"type": "null"}]
in normal JSON Schema instead or asnullable: true
if using the OpenAPI JSON Schema dialect.resource.Conf
to determine (default) rendring for empty fields.The text was updated successfully, but these errors were encountered: