|
|
|
|
|
|
by leokun
4584 days ago
|
|
|
Given that it uses reflect I bet your library very slow. I wonder how it compares to parsing JSON in Python or node.js. > except for null/undefined, That's not a small issue. Not only do JSON responses for API's vary a great deal from request to request, some handle errors without HTTP response code's. So the JSON you get back can be very different then you might expect otherwise. |
|
|
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.