Elasticsearch: 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?