Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Order of the JSON

blog.almaer.com

Post reply on HN
Print view View original

71–80 of 126 posts

Re: The Order of the JSON

#71

Post by al_form2000 »

viraptor wrote: post #58
al_form2000 wrote: post #54

"Why would you care what order we were sending the name value pairs for this?" The article makes it sound like it's somehow IBM's fault. However, questions about preserving order in hashes/associative arrays/maps/whatchamacallit span at least thirty years. Some applications of the format even demand it (e.g. ansible uses YAML - a superset of JSON - or even straight JSON for it playbooks; emitting them out of order is…

Json has a perfectly fine order preserving key-value map: [["Key1", "value1"], ["key2", ... You just need to deserialise it into a specific collection on the receiver. It's within standards and there are no weird parser issues.

That's a way. A way that, IMHO, vastly diminishes its expressive power on the reader's side, which I do not consider a very good thing. Most solutions to the issue are of this nature.

Consider serialized JSON already has a natural ordering, which is thrown away for some reason (probably parsing convenience).

Re: The Order of the JSON

#72

Post by al_form2000 »

josephg wrote: post #64
al_form2000 wrote: post #54

"Why would you care what order we were sending the name value pairs for this?" The article makes it sound like it's somehow IBM's fault. However, questions about preserving order in hashes/associative arrays/maps/whatchamacallit span at least thirty years. Some applications of the format even demand it (e.g. ansible uses YAML - a superset of JSON - or even straight JSON for it playbooks; emitting them out of order is…

I hear that. But also, JSON does not have a canonical serialisation. Other than object key ordering, strings have multiple equivalent formats (direct Unicode characters, \u00xx, \xXX, etc). Numbers have exponential form (1e2 is the same as 100). And white space is ignored - [2] and [ 2 ] and [2\n] are all equivalent. If your application expects JSON input to conform to one particular set of decision points here, that…

Agree. Except that the sheer number of questions about this spell "missed use case" - to my eyes at least. Sort of like the "How do I push a local branch to remote?" question in GITland.

Re: The Order of the JSON

#73

Post by scandinavian »

aflag wrote: post #43
cryptonector wrote: post #13

Ha! Stephen Dolan had to add this to jq quite sometime back, making it preserve object key input order on output. And yes, it's infuriating, but it's also somewhat convenient, and yes, there really is software out there that cares about object key order (sigh).

Doesn't anything using jwt depend on a specific order?

It shouldn't, unless you base64 decode the header, then parse it with a library that causes the order to change, encode it again, and then use your own re-encoding to calculate the signature:

  HMAC-SHA256(
    b64(reencoded_header) + '.' + b64(payload),
    secret
  )
You should really just verify the signature for the provided header + payload in their base64 encoded form.

Re: The Order of the JSON

#74

Post by moby_click »

jwilliams wrote: post #67
moby_click wrote: post #62

Earlier quoted context omitted.

If you require serialized JSON in a specific order, you are not requiring JSON, but some dialect of JSON and that should be clearly communicated. If, for some reason, a client needed a special serialization, i'd ask them for a spec, because the JSON spec does not apply anymore, and be done with it.

I think my argument is a bit different -- sure, this is an interface (maybe to a COBOL copybook in this case?). And yes, it's not "JSON". Agree it's a leaky abstraction. Equally agree it should be documented. Often legacy systems have weirdness after seeing decades of edge-cases. Weirdness that makes them robust in all sorts of unlikely ways. Equally makes them poorly documented, leaky, opaque, and frustrating. But I…

Yes, that sentiment is highly unprofessional. 9x6 months translates to "that box is checked for reason" and "it's not going to change". Even if things are going to change, it's probably going to affect one function on your part and you are producing valid JSON anyway. Surely you can bill a fortune 500 company for a function to put things in order.

Re: The Order of the JSON

#75

Post by tr33house »

lacker wrote: post #6

I agree the system described is crazy. However, I find it frequently useful to use ordered JSON as a data format and I think it would be handy if more languages supported it. For one, it makes it a lot easier to write integration tests using a “golden file” of ideal output, because your program that outputs JSON now usually deterministically has one correct output. For two, it lets you hash a json-encoded object dete…

makes sense. As a workaround, I'd read both, convert to a comparable object and then compare

Re: The Order of the JSON

#76

Post by Sean1708 »

Ididntdothis wrote: post #5

This sounds very familiar. A lot of companies are full of people who have no curiosity and no ability to think for themselves. I have seen it multiple times where someone claimed a change is impossible or takes insane effort. Then you have someone competent look at it and you have a solution in an hour. I think stuff likes this is the real price of not hiring really good people.

What I see far more often is people who think they're competent coming along and giving you a solution in an hour. What they don't tell you is that their solution assumes that everything works the way they think it does, and when it inevitably doesn't it takes another 5 people 5 weeks to design and implement a decent solution that actually works. But of course by this time the original rockstar has pissed off to something new and doesn't need to clean up their own mess.

I'm not bitter at all...

Re: The Order of the JSON

#77

Post by viraptor »

al_form2000 wrote: post #71
viraptor wrote: post #58

Earlier quoted context omitted.

Json has a perfectly fine order preserving key-value map: [["Key1", "value1"], ["key2", ... You just need to deserialise it into a specific collection on the receiver. It's within standards and there are no weird parser issues.

That's a way. A way that, IMHO, vastly diminishes its expressive power on the reader's side, which I do not consider a very good thing. Most solutions to the issue are of this nature. Consider serialized JSON already has a natural ordering, which is thrown away for some reason (probably parsing convenience).

> which is thrown away for some reason (probably parsing convenience).

It's got nothing to do with parsing. The json comes from JavaScript syntax, where objects represent unordered mapping. Json naturally does the same.

If you want expressive power for reading, json is very poor in comparison to pretty much everything else. Just use it for simple serialisation.

Re: The Order of the JSON

#78

Post by Frost1x »

Ididntdothis wrote: post #5

This sounds very familiar. A lot of companies are full of people who have no curiosity and no ability to think for themselves. I have seen it multiple times where someone claimed a change is impossible or takes insane effort. Then you have someone competent look at it and you have a solution in an hour. I think stuff likes this is the real price of not hiring really good people.

All problems are easy when you already have the solution or pieces to build the solution. Real world problems vary wildly and you may find someone who can solve one problem trivially while they struggle on something else that seems simple.

This condescending perspective on problem solving is part of the problem with this entire industry and ultimately turns people into tools for disposal by businesses.

Re: The Order of the JSON

#79

Post by carlmr »

>I got to learn that we were talking to a service running IBM DataPower Gateway which sat on top of WebSphere which sat on top of the COBOL.

As soon as you read IBM you know you have bigger problems than COBOL in your system.

Re: The Order of the JSON

#80

Post by cntlzw »

jwilliams wrote: post #46

(I've used both DataPower and COBOL - I've got a healthy respect for robust, long-lived legacy systems). I must admit I was scratching my head on this. The JSON spec might not specify order, but the serialized JSON is ordered by nature. JWT needs it for example (and I'd assume many signature models). Or you might have a caching layer that needs it. Maybe unchecking this causes the legacy backend to get hammered? Ther…

Justgoogled DataPower, out of curiosity, and I found XML Accelerator XA35. I did not know there is HARDWARE for XML PROCESSING! Blows my mind.
Post reply on HN