In REST Assured, which querier getters show a spec's path placeholders and their values?

## Placeholders and values are two different questions A REST Assured path such as `/api/v2/zones/{zoneId}/vents/{ventId}` has two things worth asking about. *Which braces are in it?* and *which of them have a value?* `QueryableRequestSpecification` answers them with two different families of getters, and mixing the families up is where most confusion starts. | Question | Getter | |---|---| | Which placeholders exist at all? | `getPathParamPlaceholders()` | | Which placeholders are still unfilled? | `getUndefinedPathParamPlaceholders()` | | Which named values were supplied? | `getNamedPathParams()` | | Which positional values were supplied? | `getUnnamedPathParams()`, `getUnnamedPathParamValues()` | | All supplied values together | `getPathParams()` | | What does the path look like now? | `getUserDefinedPath()`, `getDerivedPath()` | ## The two placeholder lists Both scan the path REST Assured will actually request — the path from the base URI, plus the base path, plus the path handed to the verb — so placeholders written into `setBasePath(...)` are found just as readily as ones written into `get("/zones/{zoneId}")`. - `getPathParamPlaceholders()` returns every placeholder name in that path, whether or not a value exists for it. Think of it as the shape of the template. - `getUndefinedPathParamPlaceholders()` first applies the values it has, then lists what is left. On the greenhouse specification above with `zoneId` supplied, it returns just `ventId`. The difference between the two lists is exactly the set of values you still owe the request, which makes it the natural thing for a specification factory to assert before it hands the spec out. ## The four value getters - `getNamedPathParams()` — values supplied by name, through `pathParam(name, value)`, `pathParams(Map)` or `RequestSpecBuilder.addPathParam(...)`. - `getUnnamedPathParams()` — positional values paired with the placeholder each one filled. The pairing only exists where a value actually matched a placeholder, so an extra positional value has no entry here. - `getUnnamedPathParamValues()` — the raw positional values as a list, with no pairing attempted. This is what you read when you want to know what was passed rather than where it landed. - `getPathParams()` — the named values plus the unnamed ones whose keys do not collide with a named key, in one map. It is the convenient summary; the other three are the precise answers. All four come back through `Collections.unmodifiableMap` or `unmodifiableList`, so they are for reading only. ## What the path getters show Two more getters make the picture concrete rather than abstract: - `getUserDefinedPath()` returns the path as it was written, placeholders intact — the template. - `getDerivedPath()` returns the same path with the values that are known already substituted in, so an unfilled placeholder is still visible in the middle of it. On the greenhouse specification that is `/api/v2/zones/z-17/vents/{ventId}`, which shows the state of the request at a glance. Both reflect the path the verb supplied, which is empty until a verb has been called; placeholders living in the base path still appear in `getPathParamPlaceholders()` regardless. ## Where you use this The realistic use is a guard on a shared specification or a factory method. A greenhouse climate suite that builds `zoneSpec` centrally can assert that after the factory runs the specification still owes exactly one value, `ventId`, and that `zoneId` is already pinned to the site under test. That is a cheap object-level check with no server behind it, and it turns a class of late, confusing request failures into an immediate, named test failure. The same read-back is what you reach for when a merged specification appears to have lost a path value: compare `getNamedPathParams()` with `getPathParamPlaceholders()` and the gap names itself. ## Choosing which getter to reach for The getters look interchangeable and are not. A short decision list keeps them straight: - Asking *is this specification complete?* — subtract nothing, just check that `getUndefinedPathParamPlaceholders()` is empty. - Asking *did my factory pin the right zone?* — read `getNamedPathParams().get("zoneId")`, which answers about the named value specifically rather than about the path as a whole. - Asking *what will this request address?* — read `getDerivedPath()`, or `getURI()` if you want the host and query string with it. - Asking *what template was written?* — read `getUserDefinedPath()`, which never substitutes anything. ## A note on mutability Every map and list on this family of getters is wrapped before it is returned, so a missing value cannot be supplied by writing into the result. Adding one goes back through the specification — `pathParam(name, value)`, `pathParams(Map)` or the builder's `addPathParam(...)` — and removing one goes through `removeNamedPathParam`, `removePathParam` or `removeUnnamedPathParam` on `FilterableRequestSpecification`. The read side and the write side are deliberately separate interfaces, and holding that distinction in mind is most of what it takes to use these getters without surprise.