In REST Assured, why do getRequestParams, getQueryParams and getFormParams return different maps?

## Three setters, three maps, three getters REST Assured does not keep one parameter bag. A `RequestSpecification` holds separate internal maps, and `QueryableRequestSpecification` exposes each one under the getter that matches the setter which filled it: | You called | The value lands in | You read it back with | |---|---|---| | `param(...)` / `params(...)` / `RequestSpecBuilder.addParam(...)` | the request-parameter map | `getRequestParams()` | | `queryParam(...)` / `addQueryParam(...)` | the query-parameter map | `getQueryParams()` | | `formParam(...)` / `addFormParam(...)` | the form-parameter map | `getFormParams()` | | `pathParam(...)` / `addPathParam(...)` | the named path-parameter map | `getNamedPathParams()` | The mapping is one for one, and it is total: nothing ever migrates between the maps while the specification is alive. Read the wrong one and you get an empty result and a confusing five minutes. ## Why the specification refuses to resolve `param` `param(...)` is deliberately untyped. Where it ends up depends on the HTTP verb — a request parameter becomes part of the query string on most methods and part of the form body on a POST — and a specification does not know the verb. `getMethod()` reads `null` until an HTTP verb has been issued. So the specification stores the value in the request-parameter map and leaves the decision to dispatch time. That is why: - `new RequestSpecBuilder().addParam("sensor", "co2").build()` gives an **empty** `getQueryParams()`. - The same specification gives `"co2"` from `getRequestParams().get("sensor")`. - Nothing you can query before the verb will tell you whether that parameter ends up in the URL or in a form body, because the library has not decided yet either. The practical rule: if you want to know what was *set*, read the map that matches the setter. Use the explicit `queryParam` and `formParam` on the setting side whenever the destination matters, and then the read-back is unambiguous too. ## The getter that does show a resolved request line There is one exception, and it is the useful one. `getURI()` assembles the request line as it stands: it merges base URI, base path, path and the parameters, folding the request parameters into the query string for anything that is not a POST, adding the query parameters, and adding form parameters when the method is GET. So for the greenhouse readings specification: - `getRequestParams()` answers *what did I set untyped?* - `getQueryParams()` answers *what did I set explicitly as a query parameter?* - `getURI()` answers *what does the URL look like right now?* Use the maps for assertions about intent, and `getURI()` for an assertion about the resulting URL. Note that `getURI()` is evaluated against whatever method the specification currently carries, so on a specification that has never been given a verb it behaves as a non-POST. ## Reading the wrong map — the symptoms The failure mode is quiet, which is what makes it worth knowing: - A guard test asserts `getQueryParams()` on a specification built with `addParam(...)` and finds nothing, so the author concludes the querier is broken. - A parameter appears in the request log but not in the map the test reads, so the test is weakened to a log assertion. - A merged specification seems to lose a parameter, when in fact both specifications wrote to different maps and both values are present under different getters. Checking all three maps, or checking `getURI()`, resolves every one of these in seconds. ## Changing what you find All three maps come back through `Collections.unmodifiableMap`, so mutating them throws `UnsupportedOperationException`. Adding goes through the specification's own setters. Removing goes through `FilterableRequestSpecification`, which extends the queryable interface and adds `removeParam`, `removeQueryParam` and `removeFormParam` — that is the pairing to remember: the queryable half reads, the filterable half edits, and a filter receives an object that does both. ## What a good guard test asserts Because all of this is object state, the check is cheap enough to keep permanently. For the greenhouse readings specification, one small test is enough: 1. Assert `getQueryParams().get("granularity")` equals the value the suite depends on, so a change to the factory is caught immediately. 2. Assert `getRequestParams()` is empty if the team's convention is to use only the explicit setters — that turns the convention into something enforced rather than merely agreed. 3. Assert `getURI()` contains the parameters you expect in the URL, which is the closest thing to a wire-level assertion you can make without a server. The last one is worth the extra line. Intent and result are different questions, and a specification that carries the right values in the wrong map still produces a URL you did not intend the moment a verb turns up and resolves them.