If you’re branching logic due to the existence or non-existence of a field rather than the value of a field (or treating undefined different from null), I’m going to say you’re the one doing something wrong, not the Java dev.

Ya, having null semantics is one thing, but having different null and absent/undefined semantics just seems like a bad idea.

Not really, if absent means “no change”, present means “update” and null means “delete” the three values are perfectly well defined.

For what it’s worth, Amazon and Microsoft do it like this in their IoT offerings.

Zalando explicitly forbids it in their RESTful API Guidelines, and I would say their argument is a very good one.

Basically, if you want to provide more fine-grained semantics, use dedicated types for that purpose, rather than hoping every API consumer is going to faithfully adhere to the subtle distinctions you’ve created.

They’re not subtle distinctions.

There’s a huge difference between checking whether a field is present and checking whether it’s value is null.

If you use lazy loading, doing the wrong thing can trigger a whole network request and ruin performance. Similarly when making a partial change to an object it is often flat out infeasible to return the whole object if you were never provided it in the first place.

The semantics of the API contract is distinct from its implementation details (lazy loading).

Treating null and undefined as distinct is never a requirement for general-purpose API design. That is, there is always an alternative design that doesn’t rely on that misfeature.

As for patches, while it might be true that JSON Merge Patch assigns different semantics to null and undefined values, JSON Merge Patch is a worse version of JSON Patch, which doesn’t have that problem, because like I originally described, the semantics are explicit in the data structure itself. This is a transformation that you can always apply.

No there isn’t.

Tell me how you partially change an object.

Object User :

{ Name: whatever, age: 0}

Tell me how you change the name without knowing the name. You fundamentally cannot, meaning that if you either have to shuttle useless information backs nd forth constantly, or create a useless and unavailable number of endpoints.

As others have roundly pointed out, it is asinine to generally assume that undefined and null are the same thing.

As I already said, it’s very simple with JSON Patch:

[ { *op": "replace", "path": "/Name™, "value": "otherName"} ]

Good practice in API design is to permissively accept either undefined or null to represent optionality with same semantics (except when using JSON Merge Patch, but JSON Patch linked above should be preferred anyway).

I.e. waste a ton of bandwidth sending a ridiculous out of data because your backend engineers don’t know how to program.

Gotcha.