Trying to understand JSON…
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.”
I don't get it. The key still gets declared, but it's value is null. "name" in an empty object would return undefined, not null, correct?
(Yes, this joke whooshed, but I am curious now.)
Indeed, and that turns out to be a problem if the JavaScript expects the key not to be there, but instead it is there. And then you try to tell the backend dev that the key shouldn’t be there, but he’ll try to convince you that it’s the same whether the key is not there or whether it’s assigned
nulland then you wonder if he’s messing with you, but actually he isn’t and then the only thing keeping you sane is bitching about it in meme form on lemmy.I've worked back and front end, and with a lot of developers, and I don't think anyone would say they're the same. Software devs are some of the most pedantic people out there.
For many uses it is semantically the same.
But for cases where you need to know if something was intentionally set to null or was simply not set, the difference is enormous.If I remember it correctly, per the JSON definition when a key is present but not expected it should be ignored.
The reason for that is to maintain compatibility between versions: it should be possible to add more entries to the data and yet old versions of the software that consumes that data should still continue to operate if all the data they're designed to handle is still there and still in the correct format.
Sure, that's not a problem in the blessed world of web-based frontends where the user browser just pulls the client code from the server so frontend and backend are always in synch, but is a problem for all other kinds of frontend out there where the life-cycle of the client application and the server one are different - good luck getting all your users to update their mobile apps or whatever whenever you want to add functionality (and hence data in client-server comms) to that system.
(Comms API compatibility is actually one of the big problems in client-server systems development)
So it sounds like an issue with the way your JavaScript library handles JSON or your own implementation not handling per-spec the presence of data which you don't use.
Granted, if the server side dev only makes stuff for your frontend, then he or she needs not be an asshole about it and can be more accomodating. If however that data also has to serve other clients, then I'm afraid you're the one in the wrong since you're demanding that the backwards compatibility from the JSON spec itself is not used by anybody else - which as I pointed out is a massive problem when you can't guarantee that all client apps get updated as soon as the server gets updated - because you couldn't be arsed to do your implementation correctly.
there is no "undefined" in java. this would either be a map containing the key value pair ("name", null) or it would be mapped to an object of some class with an attribute "name" which can hold a null value. in any case {} wont equal {"name":null}.
There's no "undefined" in JSON either
Yeah, I'm also confused. If an attribute is null, I would prefer to simply not serialize it.
I'm sure there are edge cases where someone might prefer to include null attributes, but generally they should be treated the same either way.
Imagine you're writing a CRUD API, which is pretty common.
If null attributes aren't included in the payload, and someone does an update (typically a PATCH), how do you know which fields should be nulled out and which should be ignored?I agree for many cases the two are semantically equivalent, but it's common enough to not have them be equivalent that I'm surprised that it causes arguments
Ah yes the difference between "unset" and "intentionally set to null", the bane of API devs who work in languages that don't inherently distinguish between the two.
If your Java dev is using Jackson to serialize to JSON, they might not be very experienced with Jackson, or they might think that a Java object with a null field would serialize to JSON with that field omitted. And on another project that might have been true, because Jackson can be configured globally to omit null properties. They can also fix this issue with annotations at the class/field level, most likely
@JsonInclude(Include.NON\_NULL).More details: https://www.baeldung.com/jackson-ignore-null-fields
C# devs be like
public string? Name { get; set; }Well. To Java that's just a string of utf-8 characters, assuming you haven't bastardised the encoding, and it's just yanked out of an HTTP entity. So of course they're different.
If you're using some json parser and object mapping library (like Jackson) then all bets are off 'cause it could be configured any which way.
On every other language and library it's whatever the defined behaviour is.
3/10
{"name": undefined}is also different, checking with something like hasOwnThat’s not legal serialized json, in the context of how any lib in Java (that I’m aware of) would either parse or render it.Ignore me, I misremembered, sorry about that.
Both instances are legal serialized JSON. What makes you think otherwise?
This is true in Lua as well (substituting 'nil' for 'null)