UI incorrect display of type: integer format: int64 as rounded int values in response body

[rgunn]

swagger.json correctly shows the data types and format but the values displayed in the response body are rounded int values.

[webron]

Rounded int values?

[rgunn]

swagger.json properties are correctly typed

"someKey":{"type":"integer","format":"int64"},
"anotherKey":{"type":"integer","format":"int64"},

The raw JSON returned from my REST service is correct but the values displayed in the swagger response body:

"someKey": 1253261109769874400,
"anotherKey": 212081872531357440,

Should be:

"someKey": 1253261109769874438,
"anotherKey": 212081872531357452,

Which is exactly the same result as running JavaScript's
parseInt("1253261109769874438")
/*
1253261109769874400
*/

I am new to swagger and have produced swagger 2 spec for approx 70 REST API endpoints and this is the only issue I have. Javascript only supports 53 bit integers and the UI does not process these values properly although I assumed it would according to the "format" type ?

[scott-orleman]

What news of this issue? Having the same problem.

[webron]

I believe this is a javascript limitation. Not sure there's much we can do about it, but ideas are welcome.

[code-ape]

I personally would like to see this resolved if possible. A project I've worked on has had to be rearchitectured because of this limitation of the values presented in the UI being rounded. We had been using 64 bit hashes.

[bobvanluijt]

Not sure if this is still an issue, but for other projects I've used this package to deal with large integers: https://www.npmjs.com/package/big-integer

[webron]

@bobvanluijt thanks for that, it's still an issue, yes. Would you consider submitting a PR that would add support for it?

[heldersepu]

This is caused by JSON.parse you can see it in response-body.jsx#L25

Try this on the browser console:

JSON.parse("{\"MyInt64\":1253261109769874438,\"MyData\":\"1253261109769874438\"}")

{MyInt64: 1253261109769874400, MyData: "1253261109769874438"}

[heldersepu]

Perhaps we should have a config option to bypass the prettification, and always render response as PlainText. Or a way to alternate between the RAW & Parsed views

Found this project: https://github.com/josdejong/lossless-json
looks like a nice candidate but the owner is very clear about the performance:
(Spoiler: lossless-json is much slower than native)

[shockey]

I think a Pretty/Raw switcher is the right answer here, as it offers a more generalized approach

[heldersepu]

@shockey 100% agree, you can merge this issue with #4018

[webron]

Closing this as a JavaScript limitation, with the suggested alternative of #4018. Not sure there's more we can do about this one beyond it.

[shockey]

I'm reopening this — the ECMAScript BigInt proposal is in stage 3 with support in latest Chrome, Firefox, and Opera, so JavaScript itself may not be a limitation here going forward.

[breun]

It seems not all browsers support BigInt yet, like for instance Safari: https://caniuse.com/#feat=bigint

[RSully]

There is some discussion about Safari's BigInt support here: mdn/browser-compat-data#4848

There is a Webkit bug being tracked for this feature, and the latest dependency there has updates recently, so it sounds like they're working on it. Fingers crossed!

[zapek]

This problem is really nasty. It's not obvious for someone using Swagger UI for checking the output of the REST API that Javascript uses float for everything and the number showing up there might be wrong.

[tim-lai]

Closing this issue again. On the subject of BigInt, JSON specification, section 6 (Numbers) is quite clear about supported number ranges. Going beyond them creates issues of correctly interpreting numbers.

In addition, exposing integers via API in JSON format that may be really big is not a good idea. One can accidentally generate a number that is outside of the range, and different platforms consuming the JSON will interpret the number differently. Even JSON:API has a convention of sending numbers as strings to avoid that problem.

Some time ago JavaScript landed a new type BigInt that can support ranges outside of 253 - 1. Unfortunately this type is not JSON serializable and the only recommended way of transferring it via JSON is: transfer it as a string. That way, every platform can deal with it as it likes.