In REST Assured, which settings control how JsonPath materialises JSON numbers?

## Two knobs, mirrored on two classes JSON has one number type; Java has several. Somebody has to choose, and in REST Assured that choice lives in two settings that appear twice — once on `JsonPathConfig`, which configures a standalone `JsonPath`, and once on `JsonConfig`, which is the wrapper that sits inside `RestAssuredConfig` and drives the `given()...then()` DSL. They carry the same two values and mean the same thing; only the entry point differs. ## numberReturnType — exactly four values | Value | Effect on a decimal such as 0.82 | Effect on a whole number such as 3 | |---|---|---| | `FLOAT_AND_DOUBLE` (default) | `Float`, or `Double` above `Float.MAX_VALUE` | left as `Integer` / `Long` | | `DOUBLE` | always `Double` | left as `Integer` / `Long` | | `BIG_DECIMAL` | left as the parser's `BigDecimal` | left as `Integer` / `Long` | | `BIG_INTEGER` | left as the parser's `BigDecimal` | converted to `BigInteger` | The mechanism is worth knowing because it explains the asymmetry. The parser underneath is a copy of Groovy's slurper, and it produces a `BigDecimal` for every non-integer literal and an `Integer` or `Long` for whole numbers. REST Assured then post-processes: - Under the two float-ish modes it narrows the `BigDecimal` by calling `floatValue()` or `doubleValue()`. - Under `BIG_DECIMAL` it does nothing, so you keep the parser's own value. - Under `BIG_INTEGER` it leaves decimals alone and instead widens `Integer` and `Long` results. So `BIG_DECIMAL` and `BIG_INTEGER` are not two halves of one "big numbers" mode — they touch opposite halves of the payload, and switching to `BIG_INTEGER` breaks every `equalTo(3)` in a suite while leaving the decimals exactly as they were. ## numberLengthLimit — a denial-of-service cap, added in 6.0.1 A JSON document can contain a numeric literal thousands of digits long. Parsing one into an arbitrarily large `BigInteger` is quadratic in CPU and heap, which made oversized literals a cheap denial-of-service against anything parsing untrusted JSON. 6.0.1 added a cap: - The default limit is **1000 characters**, matching the equivalent default in Jackson's stream-read constraints. - A longer token throws a parse exception whose message names both the token length and the configured limit, and points at the setting. - A **negative** value disables the check entirely. - The setting exists on both `JsonPathConfig` and `JsonConfig`, and is the only reason most suites will ever touch either class. Raising it is reasonable when you deliberately test very large numbers; disabling it in a suite that points at anything you do not control is not. ## Where to set them ```java // DSL-wide RestAssured.config = RestAssured.config() .jsonConfig(jsonConfig().numberReturnType(NumberReturnType.BIG_DECIMAL)); // one request only given().config(RestAssured.config().jsonConfig(jsonConfig().numberReturnType(BIG_DECIMAL))) .when().get("/glossaries/ui-strings"); // a standalone JsonPath JsonPath path = new JsonPath(rawBody) .using(jsonPathConfig().numberReturnType(NumberReturnType.BIG_DECIMAL)); ``` The two sides do not see each other. Setting `RestAssured.config` does not change how a `JsonPath` you constructed yourself behaves, and setting the static `JsonPath.config` does not change what the DSL does. That split surprises people who set one and assert through the other, and it is the first thing to check when a configuration change appears to have had no effect. ## Choosing a model for a real suite For a translation-glossary API whose entries carry a `confidence` score, the practical questions are: 1. **Does exactness matter?** If the test asserts a band — confidence above 0.5 — the default is fine and costs nothing. If it asserts a stored decimal exactly, `BIG_DECIMAL` removes the binary-representation argument from every future discussion. 2. **Who else reads these values?** A model change is global to everything the configuration covers, so it lands on every assertion at once. Make it deliberately, in one commit, with the suite green before and after. 3. **Is any of this JSON untrusted?** If a test can be pointed at an environment you do not own, leave `numberLengthLimit` alone. When you do choose `BIG_DECIMAL`, build the expected value from a **string** — `new BigDecimal("0.82")` — because `BigDecimal.equals` compares scale as well as value, and constructing one from a `double` gives you the binary approximation you were trying to avoid. ## Mistakes this surface produces - Setting the model on one side and asserting through the other, then concluding the setting is broken. - Reading `numberLengthLimit` as a precision or rounding control. It counts characters in a token and discards nothing; it either admits the literal or throws. - Assuming `BIG_DECIMAL` and `BIG_INTEGER` are two spellings of the same idea, and switching between them when an assertion fails. - Turning the length cap off globally because one fixture carries a long literal, rather than raising it for that one configuration. - Comparing a `BigDecimal` built from a `double` against a parsed one and blaming the parser for the scale mismatch that follows.