Handling big longs/ integers by REST layer

[mayya-sharipova]

Some ES clients can't handle well big integers that ES server may pass to them. For example:

• ES JS client can't handle well integer number >= 2^53 (For details see comment).
• Kibana has a similar issue
• ES PHP client: it supports 64-bit integer but not unsigned. We can support BigInteger using the GMP extensions of PHP (not default in the language).

It would be nice if a client can tell the ES server in what form it expects these big integers to be returned.

---

As an example, I am adding @ezimuel suggestion here:

• add a bigint_as_string=1 in the query string (0 by default) to return 64-bit and BigInteger as string; this will prevent JSON decoder to throw errors if numeric > 32-bit.
• add a numeric_type field in the response that will alert the client for using 64 (bit) or big (as BigInteger). This alert will not have 32 (bit) value, as default. This alert will be triggered if at least one numeric value in the response is 64 or big.

[elasticmachine]

Pinging @elastic/es-search (:Search/Search)

[elasticmachine]

Pinging @elastic/es-core-infra (:Core/Infra/REST API)

[delvedor]

It would be nice if a client can tell the ES server in what form it expects these big integers to be returned.

But also how these big integers are sent to Elasticsearch :)
I think that if we go down the path of the bigint_as_string query parameter, ES should both send and accept bigint as strings.

In addition to what we said in #32434, I think that supporting bigint as strings in the rest layer it's important for Elasticseach, as one of its best features is that it's very easy to connect to it with any language/platform. Maintaining this interoperability would allow having enough flexibility to support any use case, and keeping the getting started experience flawlessly. What do you think?

[rjernst]

I'm hesitant to have a flag that is supposed to work across the entire REST response. It is really the responsibility of the code writing each section of the response to determine the appropriate format. This seems very similar to me to the print format for date fields, where each individual date field controls how it is printed. That would be a more direct and easy approach to returning bigints as strings since field mappers already have the concept of formatting a value from a field.