skip to content

URL and Method

3 roadmaps4 questions

Matching the whole URL with its query string versus the path alone, literally or by regex, plus path templates and method choice. Interviewers ask because the two diverge once a query appears.

on this pageshow

explore

questions

4

In WireMock, how do any() and anyUrl() widen a stub, and what does each leave unconstrained?

level: seniorimportance: must knowfreq 55%

answer

  1. two dials, not one
  2. one covers method, one covers URL
  3. any() is the builder, anyUrl() the matcher
  4. turning both gives the widest pattern
  5. get(anyUrl()) still pins the verb

basics

~20 s

In WireMock, any() is a request-pattern builder that accepts every HTTP method while still applying the URL matcher you give it. WireMock's anyUrl() is a URL matcher that accepts every URL. Together they widen two separate axes.

solid answer

~40 s

WireMock separates two things that a single "wildcard" idea usually blurs. `any(` is a request-pattern builder like `get(` or `post(`, except that it accepts **any HTTP method**; it still takes a URL matcher, so `any(urlPathEqualTo("/bindery/v2/orders"))` pins the path and loosens only the verb. WireMock's `anyUrl()` is the URL matcher that accepts **any URL**; it says nothing about the method, so `get(anyUrl())` still fires only on GET. Put both together and `any(anyUrl())` is the widest request pattern WireMock can express — every request the server receives is a candidate. The habit worth building is to read a stub head as two dials and ask which one you actually meant to turn: loosen the method when a bookbindery endpoint answers several verbs identically, loosen the URL when the method genuinely is the criterion.

code

java · 13 lines
java
import static com.github.tomakehurst.wiremock.client.WireMock.*;

// URL pinned, method wide open: GET, POST and DELETE all match
stubFor(any(urlPathEqualTo("/bindery/v2/orders/BND-4417"))
    .willReturn(aResponse().withStatus(200)));

// Method pinned, URL wide open: every GET matches, whatever the path
stubFor(get(anyUrl())
    .willReturn(aResponse().withStatus(404)));

// Both dials open: the widest request pattern WireMock can express
stubFor(any(anyUrl())
    .willReturn(aResponse().withStatus(501)));

go deeper

for a junior

Remember that WireMock's any() accepts any HTTP method and anyUrl() accepts any URL, and that they are different kinds of thing — one a request-pattern builder, one a URL matcher. Say which axis each one widens.

for a middle

Explain the four combinations of get( or any( with a URL matcher or anyUrl(), and what each one admits. Be ready to state that any(anyUrl()) is the widest request pattern WireMock can express and that anyUrl() is not a regex.

for a senior

Read an unfamiliar stub head aloud and say precisely which criterion was dropped and which survived. Show that you loosen one dial deliberately rather than reaching for the widest pattern when only the method needed to vary.

for a principal

Own the house convention for how breadth is written down: whether any( and anyUrl() may appear in a committed mapping, and how a reviewer is meant to tell an intentional wildcard from an accidental one without asking the author.

## Two dials, not one wildcard Every WireMock stub opens with a *request-pattern builder* that fixes the HTTP method, and that builder is handed a *URL matcher* that fixes the URL. They are separate mechanisms with separate vocabulary, and `any(` and `anyUrl()` are the widest setting of one dial each. Confusing them is the reason people reach for the broadest possible mapping when only one criterion needed to relax. - WireMock's `any(` sits where `get(`, `post(`, `put(`, `delete(` or `patch(` would sit. It accepts any method and takes exactly the same URL matcher argument they do. - WireMock's `anyUrl()` sits where `urlEqualTo(`, `urlPathEqualTo(`, `urlPathMatching(` or `urlPathTemplate(` would sit. It accepts any URL and imposes no pattern to anchor or escape. ## The four combinations | WireMock stub head | Method accepted | URL accepted | |---|---|---| | `get(urlPathEqualTo("/bindery/v2/orders"))` | GET only | that path only | | `any(urlPathEqualTo("/bindery/v2/orders"))` | any method | that path only | | `get(anyUrl())` | GET only | any URL | | `any(anyUrl())` | any method | any URL | Read down that table and the shape of the decision becomes obvious. Each row loosens exactly one thing relative to the row above it, and the last row loosens both at once. In WireMock terms: - `any(urlPathEqualTo("/bindery/v2/orders/BND-4417"))` still asserts the resource. A test that hits the wrong bookbindery path will not be answered by this stub. - `get(anyUrl())` still asserts the verb. A POST to the same server is not a candidate, however the path is spelled. - `any(anyUrl())` asserts nothing about the request at all. It is the only WireMock request pattern with no criterion of any kind. ## What anyUrl() is and is not WireMock's `anyUrl()` takes no argument and is not a regex. There is no pattern to anchor, no `?` to escape and no distinction between path and full URL, because it never compares anything. That makes it different in kind from `urlMatching(".*")`, which is a regex that happens to accept everything and still carries all of a regex's evaluation cost and reading cost. If you mean *no URL criterion*, `anyUrl()` says so in one token and a reviewer cannot misread it. The same clarity argument applies to `any(`. Writing `any(` says out loud "the method is not a criterion here", where five separate stubs at the same path — one per verb — say the opposite and say it precisely. ## Reading an unfamiliar stub head When you meet a stub in someone else's suite, resolve it against the two dials in order: 1. Look at the builder. If it is `any(`, the method is not a criterion and any verb will be answered. 2. Look at the URL matcher. If it is `anyUrl()`, no path or query criterion exists; if it is a `urlPath*` matcher, the query string is free; if it is `urlEqualTo(` or `urlMatching(`, the query string is pinned too. 3. Only then read the response builder, because until you know what the pattern admits you cannot say which requests will receive that response. That ordering matters because the two dials fail differently. A URL that is too wide draws in requests aimed at other endpoints; a method that is too wide draws in a different operation on the *same* endpoint, which is much harder to spot when the reply looks plausible either way. ## Turning one dial on purpose - Loosen the method with WireMock's `any(` when the bookbindery endpoint answers several verbs identically and the test's subject is the resource, not the operation. - Loosen the URL with WireMock's `anyUrl()` when the method genuinely is the criterion and the path is irrelevant or not yet known. - Keep both pinned by default: `get(urlPathEqualTo("/bindery/v2/orders"))` costs nothing extra to write and states two facts instead of none. - Prefer `anyUrl()` to a catch-everything regex, and prefer `any(` to a stack of per-verb duplicates, whenever the wide setting is the intent rather than an accident. ## The same breadth elsewhere MockServer expresses the widest pattern by omission instead of by keyword: an expectation whose `request()` declares neither `withMethod(` nor `withPath(` constrains nothing, so the breadth is visible only by what is absent. The distinction to carry away is that WireMock gives breadth a *name* on each axis. `any(` and `anyUrl()` are not synonyms and they are not interchangeable — one is a builder, one is a matcher, and a stub that uses both has deliberately stopped asking any question about the request it answers.

  • In WireMock, when would you deliberately pick any( over get( for a bookbindery order stub?
    When the endpoint answers several verbs identically and the test's subject is the resource rather than the operation — a reachability check against `/bindery/v2/orders/BND-4417`, say. WireMock's `any(` keeps the URL assertion fully intact while dropping only the method one, which is a far narrower loosening than reaching for `anyUrl()`. If the test does care which verb arrived, pin it with `get(` or `post(` so a wrong-method call fails loudly.
  • Does WireMock's anyUrl() match a request with an empty path, or one carrying a query string?
    Both. WireMock's `anyUrl()` places no constraint on the URL whatsoever, so `/`, `/bindery/v2/orders` and `/bindery/v2/orders?status=in-press` are all matched equally. It is a wildcard rather than a regex, so unlike `urlMatching(".*")` there is no pattern to anchor, nothing to escape and no path-versus-full-URL distinction to get wrong.
  • How do you narrow a WireMock stub written as any(anyUrl()) without rewriting it from scratch?
    Replace one dial at a time. Swap `anyUrl()` for `urlPathEqualTo(` or `urlPathTemplate(` to pin the resource, or swap `any(` for `get(` or `post(` to pin the verb. The two substitutions are independent, so you can tighten the URL first, confirm the stub still answers, then tighten the method — and each step tells you which criterion the suite was actually relying on.

Think of a library catalogue search with two filters: one for author and one for year. WireMock's any() is setting the author filter to "anyone" and anyUrl() is setting the year to "any year" — each is a legitimate search on its own, and turning both to "any" returns the entire catalogue.

saying these in an interview costs you the question

  • Thinking WireMock's anyUrl() also relaxes the HTTP method
  • Thinking WireMock's any() also relaxes the URL matcher
  • Reaching for any(anyUrl()) when one axis needed loosening
  • Calling anyUrl() a regex rather than a no-criterion matcher
  • Believing get(anyUrl()) still pins some path prefix
open as a page

In WireMock, how do urlEqualTo() and urlPathEqualTo() differ when a query string is present?

level: juniorimportance: should knowfreq 72%

basics

~20 s

WireMock's urlEqualTo matches the whole request URL, path and query string together. WireMock's urlPathEqualTo matches the path alone and ignores everything after the question mark. Add a query parameter and the urlEqualTo stub stops matching, while urlPathEqualTo still fires.

open as a page

In WireMock, how does a stub pin the HTTP method, and why is withMethod() not it?

level: middleimportance: should knowfreq 56%

basics

~20 s

In WireMock the method is chosen by the request-pattern builder itself — get, post, put, delete, patch or any — each taking a URL matcher. WireMock's withMethod belongs to its webhook and logged-request builders, not to stub matching at all.

open as a page

In WireMock, what does urlPathTemplate() match, and what does withPathParam() add?

level: middleimportance: nice to knowfreq 42%

basics

~20 s

WireMock's urlPathTemplate matches a request path against a template such as /bindery/v2/orders/{orderId}, ignoring the query string. Each placeholder becomes a named variable. WireMock's withPathParam then constrains one of those variables with a value matcher such as equalTo or matching.

open as a page