Skip to content

PATCH vs PUT and optional fields vs "required-but-nullable" fields #716

@Marc-Andrieu

Description

@Marc-Andrieu

There's no such thing as a "Draft issue" so feel free to close this one if you feel I'm saying bullsh*t


We do not use a single PUT endpoint (no orange in the swagger):

  • violates the REST principles
  • makes no distinction between sending sparse fields to edit an object (PATCH) and sending a whole object to add it (overwrite the old one)

Reference : https://stackoverflow.com/questions/28459418/use-of-put-vs-patch-methods-in-rest-api-real-life-scenarios


Pydantic has exclude_unset to distinguish the fields that have the default value because unset, from the fields that have the default value intentionally.
In a Pydantic object, all fields are required, in that they must be defined (have a value), even if it's the default one, most often None, and we signify that a field is not required by having a default None. And when "destructuring" it to pass the dump of the values as arguments (of a CRUD), we exclude None values from the dump with exclude_none.
So there's a confusion between the fields we declare unrequired in the endpoints, from the fields we don't want to pass down to CRUDs.

Reference : https://docs.pydantic.dev/1.10/usage/exporting_models

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions