| > Given that it uses reflect I bet your library very slow. Look carefully - what I wrote is not a library; it's a standalone binary. It's run exactly once, when you write the code, so speed isn't an issue. > That's not a small issue. Depends on the language. In Go, it's very easy to allow a JSON value to be null and/or undefined by making the value it unmarshals to a pointer (which you should be doing already anyway). What's harder (in most languages, not just Go) is dealing with a value that could be (say) either a string, or a 64-bit int. Or, worse, a string whose value just happens to be a 64-bit number. When that happens (which is thankfully rare), it breaks the "JSON should be self-documenting" motto. > So the JSON you get back can be very different then you might expect otherwise. This is an issue no matter what language you use. You have to know what the set of possible response structures is in order to know what keys to query/access. |
Oh missed that.
> This is an issue no matter what language you use.
It's a lot bigger issue when you have to define classes for each type of possible response.