Why does a REST Assured test still hit the old host after you set given().baseUri()?

A REST Assured chain that ignores the base URI you just set is almost never a bug in the library. It is the documented precedence rule doing what it was written to do: a fully qualified URL passed to the verb overrides the request's base URI, base path and — when it carries one — its port. ## The rule When the string handed to `get(...)`, `post(...)`, `delete(...)` or `request(...)` starts with a scheme (`http://`, `https://`), REST Assured treats it as the complete target. The base URI and the base path are discarded rather than merged, and the URL's own authority and path are used verbatim. The library's own integration suite names the test for this behaviour `specifyingFullyQualifiedPathOverridesValues`. So on an allotment water-rota API: - `given().baseUri("https://rota.allotment-water.test").basePath("/api/v2").get("/plots/17/slots")` reaches `https://rota.allotment-water.test/api/v2/plots/17/slots`. - The identical chain ending in `.get("http://legacy-rota.internal/plots/17/slots")` reaches `http://legacy-rota.internal/plots/17/slots` — both defaults are gone. Nothing warns you. The chain still compiles, still sends, and often still returns 200 from whatever the old host is serving, which is precisely why this survives a repointing exercise. ## What survives the override and what does not | Setting | Survives a fully qualified verb URL? | |---|---| | `baseUri` / `RestAssured.baseURI` | No — the URL's scheme and authority replace it | | `basePath` / `RestAssured.basePath` | No — the URL's own path is used as written | | `port` / `given().port(...)` | Yes, but only if the URL carries no port of its own | | Headers, cookies, params, auth, filters | Yes — the override is about the target, not the rest of the request | That third row is the subtle one. An explicit port is still appended to a scheme-carrying URL that has no port, so `given().port(9090).get("http://legacy-rota.internal/plots")` reaches port 9090 on the legacy host — the wrong host on the right port. ## Why the library behaves this way The override is a convenience, not an oversight. It lets a single test reach something outside the suite's usual target — a token endpoint on an identity host, a fixture uploaded to object storage, a health check on a neighbouring service — without disturbing the defaults every other test relies on. The `get(URI)` and `get(URL)` overloads exist for the same reason and are fully qualified by construction, so they always bypass the defaults. ## Finding it in a real suite 1. Print the URI the library actually assembled. `given().log().uri()` on the request side, or a request-logging filter registered globally, shows the full target rather than the one you intended. 2. Grep the suite for `://` inside a verb argument. Every hit is a call that ignores the base URI, and most of them are accidental copies from a browser address bar or a curl command. 3. Grep for the `URI` and `URL` overloads of the verbs, which cannot be relative and are easy to miss in a review. 4. Compare a passing local run against the failing deployed run: if one test's target is identical in both, that test is not using the defaults at all. ## Guardrails worth having - Make the verb argument **relative by convention** and enforce it — a one-line assertion in a shared helper, or a lint rule that rejects `://` in a verb argument, catches the whole class. - Keep the environment's host in **one** place so that repointing is a single edit, and treat any test that opts out as something that needs a comment explaining why. - When a call genuinely must leave the suite's target, prefer an explicit `given().baseUri("https://identity.allotment-water.test")` on that chain over an inline absolute URL. The intent is then visible, and the base path and port rules still behave predictably. - Assert on something host-specific in a smoke test — a build identifier or an environment banner in the response — so a run against the wrong host fails on an assertion rather than passing quietly. One more thing to check before blaming the rule: an absolute URL is only one of the ways a chain can leave the suite's target. A test that sets its own `given().baseUri(...)` further up the chain, or one that reuses a helper which does, reaches the same outcome by a legitimate route. The diagnostic is identical in both cases — print the assembled URI and read it — but the fix is different, because an explicit `baseUri(...)` is usually deliberate while an absolute verb path almost never is. The rule itself is short and worth stating exactly as it is: **a scheme in the verb's path means the verb's path is the whole address.**