Meme transcription: Panel 1. Two images of JSON, one is the empty object, one is an object in which the key name maps to the value null. Caption: “Corporate needs you to find the difference between this picture and this picture”
Panel 2. The Java backend dev answers, “They’re the same picture.”
Had to solve this with Go recently, which was not as straightforward as I’d hoped! https://www.jvt.me/posts/2024/01/09/go-json-nullable/
Just what every programming language needs, not one, but two types of null! Because nobody ever said one type was difficult enough.
If I see any of you make this distinction matter for anything other than “PUT vs. PATCH” semantics I’m going to be very angry.
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.
These two things SHOULD be treated the same by anybody in most cases, with the possible exception of rejecting the later due to schema mismatch (i.e. when a “name” field should never be defined, regardless of the value).
They’re semantically different for PATCH requests. The first does nothing, the second should unset the name field.
Only if using JSON merge patch, and that’s the only time it’s acceptable. But JSON patch should be preferred over JSON merge patch anyway.
Servers should accept both null and undefined for normal request bodies, and clients should treat both as the same in responses. API designers should not give each bespoke semantics.
JSON patch is a dangerous thing to use over a network. It will allow you to change things inside array indices without knowing whether the same thing is still at that index by the time the server processes your request. That’s a recipe for race conditions.
Why?
Because Java struggles with basic things?
It’s absurd to send that much data on every patch request, to express no more information, but just to appease the shittiness of Java.
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.
Except, if you use any library for deserialization of JSONs there is a chance that it will not distinguish between null and absent, and that will be absolutely standard compliant. This is also an issue with protobuf that inserts default values for plain types and enums. Those standards are just not fit too well for patching
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.
