In REST Assured, how do you fill the {orderId} placeholder in a request path?

## What a placeholder is in a REST Assured path The path you hand to `get`, `post`, `put`, `delete`, `patch`, `head`, `options` or `request(...)` is a **template**, not a finished URL. Anything between a `{` and the next `}` is a **placeholder**, and REST Assured will not send the request until every placeholder has a value. For a bookbindery order API the templates read `/orders/{orderId}` and `/orders/{orderId}/signatures/{signatureNo}`. Leaving the braces in the string — rather than concatenating an id into it — is what lets one literal path be reused across a dozen cases and read back intact in a log line. Two families of calls supply the values, and a single request may use both. ## The named form: pathParam and pathParams These are declared on `RequestSpecification`, so they belong in the `given()` half of the chain: - `pathParam(String name, Object value)` binds one placeholder: `given().pathParam("orderId", "BND-4417")`. - `pathParams(String first, Object firstValue, Object... rest)` takes alternating name/value pairs, as in `pathParams("orderId", "BND-4417", "signatureNo", 12)`. - `pathParams(Map<String, ?> map)` takes them as a map, which is what you want when the values arrive together from a fixture or from an earlier response. The name in the call must match the text inside the braces **exactly**. A placeholder written `{orderId}` is not filled by a parameter named `orderID`, and that mismatch is a runtime failure rather than a compile error. One named value covers every occurrence of that placeholder, so a template like `/orders/{orderId}/audit/{orderId}` still needs only one `pathParam("orderId", ...)` call. ## The unnamed form: index-based positional values Every request method also carries an `(String path, Object... pathParams)` overload and an `(String path, Map<String, ?> pathParams)` overload, so the values can travel with the path itself: - `get("/orders/{orderId}/signatures/{signatureNo}", "BND-4417", 12)` fills the two slots **left to right**. - The text inside the braces is never consulted in this form — position is the entire binding rule, which is why REST Assured calls these *unnamed* path parameters. - A `null` positional value is rejected before anything is built, with `IllegalArgumentException: Unnamed path parameter cannot be null (path parameter at index 0 is null)`. - The map overload is really the named form in disguise: `get("/orders/{orderId}", Map.of("orderId", "BND-4417"))` matches by key, not by position. ## Values are objects, not strings Both families take `Object`. `pathParam("signatureNo", 12)` and `get(".../{signatureNo}", 12)` are both legal, and REST Assured converts the value to its string form before splicing it into the path. That is worth more than it sounds: it keeps `String.valueOf(...)` noise out of the test, and an id held as a `Long` or a `UUID` in a fixture needs no ceremony at the call site. ## Choosing between the two forms | | named (`pathParam`) | unnamed (positional) | |---|---|---| | where it is written | in `given()`, before the verb | as trailing arguments to the verb | | what binds the value | the name inside the braces | the index of the placeholder | | survives reordering the path | yes | no | | reads well with one slot | verbose | ideal | | reads well with three or more | ideal | error-prone | The convention most suites settle on comes out roughly like this: 1. One placeholder and a literal value at the call site — use the positional form, because `get("/orders/{orderId}", orderId)` is hard to misread. 2. Two or more placeholders, or values computed earlier in the test — name them, so a reader can check `pathParam("signatureNo", 12)` against the template without counting arguments. 3. Values that arrive as a map from a data fixture — hand the map to `pathParams(Map)` and let the keys do the matching. ## What happens when the accounting is wrong REST Assured checks the count when the request is actually sent, not when you build the specification, and it throws `IllegalArgumentException` naming what it expected, what it received, and which placeholders were left over. A missed call site after a template gains a segment produces `Invalid number of path parameters. Expected 2, was 1. Undefined path parameters are: signatureNo.` The message is designed to be read rather than merely caught: the counts tell you which side is wrong, and the trailing lists tell you exactly which name or value is unaccounted for.