bleistift2Jun 30, 2024

Surely "1337" is the same as 1337, right?

https://sopuli.xyz/post/14326368

Surely "1337" is the same as 1337, right? - Sopuli

Meme transcription: Panel 1: Bilbo Baggins ponders, “After all… why should I care about the difference between int and String? Panel 2: Bilbo Baggins is revealed to be an API developer. He continues, “JSON is always String, anyways…”

Show threadRustyNovaJun 30, 2024
To whoever does that, I hope that there is a special place in hell where they for you to do type safe API bindings for a JSON API, and every time you use the wrong type for a value, they cave your skull in.
Show threadAux
Well, apart from float numbers and booleans, all other types can only be represented by a string in JSON. Date with timezone? String. BigNumber/Decimal? String. Enum? String. Everything is a string in JSON, so why bother?
Jul 1, 2024 at 10:23pmWeb
Show threadRustyNovaJul 2, 2024

I got nothing against other types. Just numbers/misleading types.

Although, enum variants shall have a label field for identification if they aren’t automatically inferable.

Show threadAuxJul 2, 2024
Well, the issue is that JSON is based on JS types, but other languages can interpret the values in different ways. For example, Rust can interpret a number as a 64 bit int, but JS will always interpret a number as a double. So you cannot rely on numbers to represent data correctly between systems you don’t control or systems written in different languages.
Show threadladJul 2, 2024
No problem with strings in JSON, until some smart developer you get JSONs from decides to interchangeably use String and number, and maybe a boolean (but only false) to show that the value is not set, and of course null for a missing value that was supposed to be optional all along but go figure that it was