diff --git a/contributors/devel/sig-architecture/api-conventions.md b/contributors/devel/sig-architecture/api-conventions.md index d7617fb1e0d..34058e98d50 100644 --- a/contributors/devel/sig-architecture/api-conventions.md +++ b/contributors/devel/sig-architecture/api-conventions.md @@ -27,6 +27,7 @@ An introduction to using resources with kubectl can be found in [the object mana - [Categories](#categories) - [Idempotency](#idempotency) - [Optional vs. Required](#optional-vs-required) +- [Nullable](#nullable) - [Defaulting](#defaulting) - [Static Defaults](#static-defaults) - [Admission Controlled Defaults](#admission-controlled-defaults) @@ -909,6 +910,26 @@ In these cases, pointers are not needed, as the zero value indicates to the stru This can be beneficial to API authors, as it reduces the complexity of the API, and reduces the risk of nil pointer exceptions in controllers. +## Nullable + +The `+nullable` comment tag allows the json `null` value to be a valid value +for a field. The `null` value is serialized only when a field is a pointer +in the Go definition, and does not have the `omitempty` json tag, or sometimes where a +custom marshal function is implemented. + +For example, a map field marked with `+nullable` would accept either `foo: null` or `foo: {}`. + +Usage of `+nullable` is discouraged as it introduces several issues: +- It is not compatible with json merge patching. + - From the [JSON Merge Patch RFC](https://tools.ietf.org/html/rfc7386#section-1): + > Null values in the merge patch are given special meaning to indicate the removal of existing values in the target. +- Explicit `null` values are not persisted in proto serializations. +- `null` values are not supported by Server-Side Apply applyconfiguration types. + - A persisted `null` value would not round-trip through the applyconfiguration type + encode/decode cycle. + +Avoid designing APIs that require the distinction between unset and `null`. + ## Defaulting In general we want default values to be explicitly represented in our APIs,