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.”
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
That’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.
That’s what undefined is for
Undefined is not part of JSON specification. It’s also not a thing in Java.
This is true in Lua as well (substituting ‘nil’ for 'null)
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 null and 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.
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.
So it sounds like an issue with […] handling per-spec the presence of data which you don’t use.
The trouble is, in this specific use case, the data may either be there or it may not be, depending on authorization. I’m checking specifically if the key is present to determine whether the user has access to that data (and display a toggle for that data), or if the user mustn’t see it and thus doesn’t need the toggle.
The wrong assumption was that if the key is there, then the value is not null. That assumption was invalidated by an update on the server side. Of course I could’ve checked if the value of the key is nullish. But it’s still annoying to have a breaking frontend because the backend changed how it serves its data.
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
For an API there should always be a version parameter/endpoint, imho.
Edit for further context: Ideally, a parameter.
If an attribute is null, I would prefer to simply not serialize it.
That’s interesting. I’m on the opposite team. If a customer model defines an optional birthday, for instance, I’d rather have it serialized as a null value if it’s not available for a specific customer.
The biggest reason for me is that it’s less data to send over a network. Especially when I’m working with lists of objects, including null fields can add a noticeable chunk to the payload.
There are some cases where it might be worth it to differentiate “No value” and “No attribute”, but in most cases they can be treated the same, since the data should really be validated against a schema anyway.
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}.