Surely "1337" is the same as 1337, right?
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…”
Many API developers may choose not to use them, but they are absolutely there.
You specify the type by including or excluding quotation marks, and then for the types without quotation marks, you either include or exclude a decimal point to specify float or integer, and for boolean you use characters (specifically true or false). Arrays are wrapped in [] and objects are wrapped in {}.
JSON data as a whole is passed as one giant string because the REST protocol demands it. But once it's been pulled in and properly interpreted, there are absolutely types in the data.
Absolutely. Who doesn’t type JSON?
We aren't using json.atChar(17) to get values?
I'm not sure if i'm missing a joke here, so:
In case you're making a joke: The people who don't type JSON are using controllers.
In case you're asking a serious question: the people who don't type JSON are the people in OP's image. They are technically using types, but that type is literally always string. They don't use integers, they don't use booleans. This is functional but may not be the best choice, depending on what kinds of data their system is supposed to handle.
Great post, but I have to "well, actually" you on this little thing:
the REST protocol demands it.
REST is not a protocol, and does not have to do anything with JSON.
(eg. How Did REST Come To Mean The Opposite of REST? by Carson Gross)
All of us fintech devs however, know the true horrors. Make everything a string, lest ye end up in precision hell
Just reminded me of an argument trying to explain that arithmetic with floating point numbers is not always correct to a coworker who was a mathematician just starting in software dev.
In a mathematicians mind the fact that an arithmetic operation can produce inaccurate result is just incomprehensible
The fun differences between the perfect world of theoretical and the realistic. Everyone thinks of computers as perfect - but it's not until you're asked to solve "How do you store decimals using only 0s and 1s?" does it start to click. Not as easy. It's why I'm hesitant to hire bootcampers into my roles. Bootcamps are great, and they get more people coding, but you don't learn that theory behind the scenes - you don't really know what the computer and operating systems are doing. For 90% of the time it doesn't matter, it's abstracted away - but that last 10% man, that can really fuck up an entire system.
Lovecraftian horror for mathematicians. Immediately goes insane.
You are a fintech dev using floating point? And your advice is to encode things as strings?
...
This is why I got out of fintech.
(I am sorry, I know there are horrors and I am sure I am not familiar with your exact scenario.)
Edit: just for anyone who passes by: try to stick with integers in a currency's smallest unit of division. (This is only one small bit of this problem, but the number of times I have seen currency values in floating point makea me psychotic.)
Until you get to multi currency, which is why I don't support using ints or longs, and strings are still the only way. There are currencies that have no precision, and others that have 3 or more digits of precision - and then you're looking at doing calculations each time. Strings are the safest way to make sure you're representing exactly what you want to when sending data over the wire or persisting
JSON numeric encoding is perfectly capable of precise encoding to arbitrary decimal precision. Strings are easier if you don't want to fuck around with the parser, though.
Correct, JSON can handle any precision, because it's just dumped as a string anyway, just not enclosed in the "". However, as you mentioned, as soon as it comes through the parser it'll put it into an underlying float value. In C# I create a save high precision attribute that will take the value and put it directly into a decimal. In JS I'm sure there's some way to do that, but that parser is way less extensible compared to C#. However, this also all assumes you know the client will parse it correctly, overriding the default behavior. Safest is to just send it as a string, and then create your parsers to automatically send to and from strings
Once we had a "sr developer" join a project from a consulting group. The project wasn't going well so me and another dev started helping with some tasks as well.
After a couple days of helping, trying to get his web application to work with data from an API he turns to us and says "oh, json is just a string."
The other developer from our team stared at him for a few seconds, stood up, walked out of the room and told the project manager something along the lines of "if that guy ever comes back in the building I'll quit"
So yeah, json is just a string... But if that's the end of your knowledge you're in for a bad day.
"if that guy ever comes back in the building I'll quit"
You can't just leave a story like that lol, did "sr dev" come back into the building? Did the other dev follow through on his threat? So many questions
Ha yeah "Sr dev" was never seen again, the team member stuck around for quite a few more years.
I love when an API takes a json payload, and one of the json fields is a string that contains json, so I have to serialize/deserialze in stages 😭
Holy shit, I’m sorry.
Though I once proposed an API like that for user preferences. I just needed “someone” (that wasn’t the client) to store a bunch of data for me. The backend doesn’t interpret it, the backend doesn’t edit it, so why should they deserialize and serialize it again? Just give it to me when I ask for it, kay?
Looks like you have a shitty arch
I feel this in my bones. As an OG dev, I had this incredible urge to smack people when I was working for my last job and I saw the API specs with everything being sent as strings through JSON. Boolean? Sure, let's use a string. Integers? Sure we'll do conversion in our code, that'll be more efficient... So fucking infuriating. Oh and don't get me started on JsonSchema T_T
Please do get started. I am curious.
JsonSchema is a way to validate some JSON. A great thing when you want to stop any sort of malformed data from coming in. Instead of wrecking your head in your code testing whether this bit here is not null, or is that string a valid boolean (I still remember that shitty piece of code they had, ugh!) or that bit is empty or that one is an actual number, or a string that can only have such and such value, well, you can formalise all this in one place, as a data file instead of code. Very convenient.
Except when it turns out you're using a JSON library that's not one, not two, but six major versions behind, and the security department won't greenlight you using anything recent because... fuck you, that's why. And to add insult to injury, we were the Quality department. Responsible for analysing the code quality of thousands of coders, around a hundred thousand programs (mostly COBOL but also C#), of a European banking group... The JSON schema was for adding a layer of non existant security to our API. But no, let's keep accepting shitty malformed JSON (because of course we kept receiving shitty JSON; that's why we wanted to implement this)
So I had to rewrite a lot of custom code to patch the bugs we found in the library, and none of the nifty tools that let you put in json and generate json schema would work for us. Heck, they even have JsonSchema to validate your JsonSchema but those wouldn't work either, so far behind our version was.
Fucking awesome experience. I'm glad it's behind me.
The meme format is awesome, but JSON differentiates strings with ".
{ "key": 1337 } vs { "key": "1337" }.
You might be thinking yaml? (Though it supports ' and " for explicit string types, technically)
But integer vs float? Good luck.
The joke is that, regardless of how the type is declared in json, you are parsing a string. (your json blob is just a series of characters, not raw binary data)
Yes. And many people here doesn't seem to get that.
I'm not a dev of any kind. I occasionally write some bash and awk scriots to automate some things and if I need some kind of plain text (non-binary) data format I prefer tsv over json.
So why do I still get this? Is it just that many json advocates want to make sure others know json does support other data types than plain string?