number parsing: raw results != non raw results about restish

[wdullaer]

I did some investigation into this.
The problem seems to be that internally the json is deserialized into a map[interface{}]interface{}. Since json.Unmarshal has no type information it choses to use float64 to deserialize number values. This is on par with other json implementations.

If you deserialize into a concrete type (say int64), json.Unmarshal will do the right thing and no precision is lost.

Theoretically, if the openapi spec provides detailed type information, we could try to be smarter when deserializing, but I didn't immediately see a quick fix.

[danielgtaylor]

Thanks for looking into this. It's a pretty difficult problem for a generic tool to solve. At this point I'm going to say this is expected behavior as so many implementations behave this way.

Also from the JSON RFC:

Note that when such software is used, numbers that are integers and
are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
sense that implementations will agree exactly on their numeric
values.

If you need to send around big numbers a common tactic in JSON is to encode them to strings. Other formats like CBOR have built-in support for big numbers.