Trying to understand JSON…
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.”
Thanks for the transcription!
Surely Java can tell the difference between a key with a null value and the absence of that key, no?
I mean, you can set up your deserialization to handle nulls in different ways, but a string to object dictionary would capture this, right?
It can, but especially during serialization Java sometimes adds null references to null values.
That’s usually a mistake by the API designer and/or Java dev, but happens pretty often.
That’s exactly not the thing, because nobody broke the contract, they simply interpret it differently in details.
Having a null reference is perfectly valid json, as long as it’s not explicitly prohibited. Null just says “nothing in here” and that’s exactly what an omission also communicates.
The difference is just whether you treat implicit and explicit non-existence differently. And neither interpretation is wrong per contract.
I think we’re fully in agreement here: if the API doesn’t specify how to handle null values, that omission means they’re perfectly valid and expected.
Imagine a delivery company’s van exploding if somebody attempts to ship an empty box. That would be a very poorly built van.
Null means I’m telling you it’s null.
Omission means it’s not there and I’m not telling you anything about it.
There is a world of difference between those two statements. It’s the difference between telling someone you’re single or just sitting there and saying nothing.
Nope.
If there’s a clear definition that there can be something, implicit and explicit omission are equivalent. And that’s exactly the case we’re talking about here.
Did you read the comments above?
You can’t just ignore context and proclaim some universal truth, which just happens to be your opinion.
Again, did you actually read the comments?
Is SQL an API contract using JSON? I hardly think so.
Java does not distinguish between null and non-existence within an API contract. Neither does Python. JS is the weird one here for having two different identifiers.
Why are you so hellbent on proving something universal that doesn’t apply for the case specified above? Seriously, you’re the “well, ackshually” meme in person. You are unable or unwilling to distinguish between abstract and concrete. And that makes you pretty bad engineers.
If your SQL model has nulls, and you don’t have some clear way to conserve them throughout the data chain, including to the json schema in your API contract, you have a bug. That way to preserve them doesn’t have to be keeping nulls distinct from missing values in the json schema, but it’s certainly the most straightforward way.
The world has more than three languages, and the way Java and Python do things is not universally correct. I’m not up to date on either of them, but I’m also guessing that they both have multiple libraries for (de) serialization and for API contract validation, so I am not really convinced your claims are universal even within those languages.
I am not the other person you were talking to, I’ve only made one comment on this, so not really “hellbent”, friend.
Yes, I am pretty sure I read the comments, although you’re making me wonder if I’m missing one. What specific comment, what “case specified above” are you referring to? As far as I can see, you are the one trying to say that if a distinction between null and a non-existent attribute is not specified, it should universally be assumed to be meaningless and fine to drop null values. I don’t see any context that changes that. If you can point it out, specifically, I’ll be glad to reassess.
At the (SQL) database level, if you are using null in any sane way, it means “this value exists but is unknown”.
Null at the SQL means that the value isn’t there, idk where you’re getting that from. SQL doesn’t have anything like JS’s undefined, there’s no other way to represent a missing value in sql other than null (you could technically decide on certain values for certain types, like an empty string, but that’s not something SQL defines).
For those who don’t know:
Speaking at a software conference in 2009, Tony Hoare hyperbolically apologized for “inventing” the null reference:[26] [27]
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
bleistift2
MostlyBlindGamer
AggressivelyPassive
JackbyDev
null and then Graydon Hoare invented Rust, immediately terminating the existence of null which does not have a traditional null value.
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.
It’s about making APIs more flexible, permissive, and harder to misuse by clients. It’s a user-centric approach to API design. It’s not done to make it easier on backend. If anything, it can take extra effort by backend developers.
But you’d clearly prefer vitriol to civil discourse and have no interest in actually learning anything, so I think my time would be better spent elsewhere.
Well, Jackson before 2.9 did not differentiate, and although this was more than five years ago now, this is somewhat of a counter example
Also, you sound like serializers are not made by developers
Excelname 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.
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.
That’s what the If-Match header is for. It prevents this problem.
That being said, I generally think PUTs are preferable to PATCHes for simplicity.
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.
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.
VeganPizza69 Ⓥ
undefined: not retrieved yet. null: Error when retrieving. Makes it easy to reason about what the current state of the data is without the need for additional status flags.