In REST Assured's RequestSpecBuilder, what is the difference between its addX and setX methods?

## Two prefixes, two behaviours `io.restassured.builder.RequestSpecBuilder` names its methods to a rule rather than a house style, and the rule tells you what a second call does. A `setX` method fills one slot on the specification being assembled, so calling it again overwrites what was there. An `addX` method appends to a collection, so calling it again leaves both entries in place. Once you read the prefix that way, most of the builder's surface stops needing to be memorised. ## The set family: one slot each These carry a single value, and the last call wins: - `setBaseUri(String)` / `setBaseUri(URI)`, `setBasePath(String)`, `setPort(int)` — where the call lands. - `setContentType(ContentType|String)`, `setAccept(ContentType|String)`, `setBody(...)` — how the payload is described. - `setAuth(AuthenticationScheme)`, `setSessionId(...)` — who the caller is. - `setConfig(RestAssuredConfig)`, `setProxy(...)`, `setUrlEncodingEnabled(boolean)`, `setKeyStore(...)`, `setTrustStore(...)` — transport-level switches. So a template that calls `setBasePath("/v2")` and later `setBasePath("/v2/depot")` carries only `/v2/depot`. That is usually what you want; it is also why a stray second call is silent rather than loud. ## The add family: append and keep These back onto lists or maps on the specification: - `addHeader(name, value)` and `addHeaders(Map)` - `addCookie(...)` (four overloads) and `addCookies(...)` - `addParam`, `addQueryParam`, `addFormParam`, `addPathParam` and their plural and `Map` forms - `addMultiPart(...)` in its several overloads - `addFilter(Filter)` and `addFilters(List<Filter>)` - `addRequestSpecification(RequestSpecification)` Calling `addHeader("X-Depot", "kirkstall")` and then `addHeader("X-Depot", "headingley")` on a milk-round template leaves **two** header entries, not one — the builder appends, and REST Assured sends both. The two exceptions are the ones you reach for through `setContentType` and `setAccept` anyway: `content-type` and `accept` are the header names REST Assured overwrites by default. ## The comparison in one table | Prefix | Backing shape | Second call with the same name | Examples | |---|---|---|---| | `setX` | one field | replaces the first value | `setBaseUri`, `setPort`, `setAuth` | | `addX` | list or map | keeps both entries | `addHeader`, `addCookie`, `addFilter` | | `removeX` | list or map | drops the named entry | `removeParam`, `removeQueryParam` | ## What the surface deliberately omits The builder is asymmetric, and the asymmetry is worth knowing before you plan a template: 1. There is **no** `setHeader`, `setCookie` or `setFilter`. If you want exactly one header of a given name in the template, add it exactly once. 2. Removal exists **only for parameters** — `removeParam`, `removeQueryParam`, `removeFormParam`, `removePathParam`. There is no `removeHeader`, `removeCookie` or `removeFilter`. 3. So a template that must *not* carry something has to be built without it. You cannot subtract a header, a cookie or a filter after the fact; you build a second, narrower template instead. That third point is the practical consequence. A team that builds one maximal specification and expects individual cases to strip pieces off it will find the header and filter parts unstrippable, and will end up with tests that quietly send more than they meant to. ## The plural and Map forms follow the same rule Several `addX` methods come in bulk shapes — `addHeaders(Map<String, String>)`, `addCookies(Map)`, `addParams(Map)`, `addQueryParams(Map)`, `addFormParams(Map)`, `addPathParams(Map)` and `addFilters(List<Filter>)`. They are still `addX`, so they still append; handing a map to `addHeaders` does not replace the headers already collected, it merges the map's entries in beside them. Nothing in the builder takes a collection and swaps out what was there before, which is the same fact stated a second way: the collection half of a specification only ever grows while the builder is alive. ## Reading the prefix as documentation Two habits follow. First, when you review spec-building code, read the prefixes before the arguments: a `setX` repeated is dead code, an `addX` repeated is probably a duplicate on the wire, and both look identical at a glance. Second, when you extend a template, prefer adding a narrow second specification and composing it with `addRequestSpecification` over piling more `addX` calls onto a shared one — composition is reversible in the sense that you can choose not to compose, while an `addX` on the common template reaches every test in the suite at once. For a milk-round suite that means one base template with the host, prefix and content type, a small `depotHeadersSpec` for the routing headers, and a `loggingSpec` for the filters you only want in CI — each built by its own builder, each composed where it is wanted.