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

middleshould knowfreq 56%

answer

the verb is in the builder
no separate method predicate exists
get(, post(, any( open the pattern
withMethod belongs to webhooks and journal
requestMatching( for what the set misses

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.

solid answer

~50 s

In WireMock the HTTP method is not a separate predicate you bolt on; it is baked into the builder that opens the request pattern. stubFor(get(urlPathEqualTo("/bindery/v2/orders"))) pins GET, and WireMock's post(, put(, delete(, patch(, head(, options( and trace( do the same for their own methods, each taking the URL matcher as its argument. WireMock's any( is the same builder with the method constraint removed, so it still applies whatever URL matcher you hand it. For a criterion the fixed set cannot express, WireMock's requestMatching( hands the whole request to a matcher you supply. The trap is withMethod(: the name does exist in WireMock, but on WebhookDefinition and LoggedRequest.Builder — the outbound-webhook and request-journal sides — so it fits nowhere in a stub definition, and searching for it in an IDE is how people talk themselves into believing it is the matching API.

In WireMock the HTTP method is not a separate predicate you bolt on; it is baked into the builder that opens the request pattern. `stubFor(get(urlPathEqualTo("/bindery/v2/orders")))` pins GET, and WireMock's `post(`, `put(`, `delete(`, `patch(`, `head(`, `options(` and `trace(` do the same for their own methods, each taking the URL matcher as its argument. WireMock's `any(` is the same builder with the method constraint removed, so it still applies whatever URL matcher you hand it. For a criterion the fixed set cannot express, WireMock's `requestMatching(` hands the whole request to a matcher you supply. The trap is `withMethod(`: the name does exist in WireMock, but on `WebhookDefinition` and `LoggedRequest.Builder` — the outbound-webhook and request-journal sides — so it fits nowhere in a stub definition, and searching for it in an IDE is how people talk themselves into believing it is the matching API.

code

java · 11 lines

java

import static com.github.tomakehurst.wiremock.client.WireMock.*;

// The method lives in the builder, not in a predicate
stubFor(post(urlPathEqualTo("/bindery/v2/orders"))
    .willReturn(aResponse()
        .withStatus(201)
        .withHeader("Location", "/bindery/v2/orders/BND-4417")));

// any( keeps the URL pinned and accepts every method
stubFor(any(urlPathEqualTo("/bindery/v2/orders/BND-4417"))
    .willReturn(aResponse().withStatus(200)));

go deeper

for a junior

Recall that a WireMock stub picks its method with the builder that opens it — get(, post(, put(, delete( — and that each one takes a URL matcher as its argument. There is no separate method predicate to add afterwards.

for a middle

Explain that any( is the same builder with the method constraint dropped, and that requestMatching( exists for criteria the fixed set cannot express. Be able to say where withMethod( really lives in WireMock and why it fits nowhere in a stub.

for a senior

Diagnose the confusion in review: a colleague reaching for withMethod( has usually carried a habit across from another stub server. Explain the two DSL shapes clearly enough that the fix is obvious rather than a compiler error to be worked around.

for a principal

Set the expectation that a stub set is written in one product's DSL and reviewed as such. Decide how a team running more than one stub server keeps the two vocabularies apart in shared helper libraries and in code review.

The method lives in the builder, not in a predicate

Most of a WireMock request pattern is built by chaining predicates — a URL matcher, header matchers, body matchers. The HTTP method is the exception. It is fixed by the static factory that opens the pattern, and there is no separate call that sets it afterwards. So a bookbindery order stub is written as stubFor(post(urlPathEqualTo("/bindery/v2/orders"))), and the word post is the entire method criterion. There is nothing to add and nothing that could contradict it later in the chain.

That is a deliberate design: because the method is chosen first, every WireMock stub has exactly one method criterion or none, and it is visible on the first line of the mapping.

The builders you actually use

WireMock's get(, post(, put(, delete(, patch(, head(, options( and trace( each open a pattern with that one method fixed, and each takes a URL matcher as its argument.
WireMock's any( opens a pattern with no method constraint while still applying the URL matcher you hand it, so any(urlPathEqualTo("/bindery/v2/orders/BND-4417")) answers every verb aimed at that one path.
WireMock's requestMatching( steps outside the fixed set entirely and hands the whole request to a matcher you write, for criteria no built-in predicate expresses.

Because the URL matcher is the builder's argument rather than a sibling call, the two axes compose cleanly: get(urlPathTemplate("/bindery/v2/orders/{orderId}")) reads as this verb, that path shape, and neither half can be changed without touching the other's slot.

Where withMethod actually lives

This is the trap the question is really about, and it is a genuine one because the name exists and autocompletes.

Name	Product	Where it lives	What it does
`get(`, `post(`, `any(`	WireMock	the `WireMock` static factories	opens a request pattern with the method fixed or free
`requestMatching(`	WireMock	the `WireMock` static factories	opens a pattern backed by a matcher you supply
`withMethod(`	WireMock	`WebhookDefinition`, `LoggedRequest.Builder`	sets the method of an outbound webhook, or of a request reconstructed from the journal
`withMethod(`	MockServer	the request model of an expectation	the method predicate of a MockServer expectation, paired with `withPath(`

The two WireMock homes for withMethod( are both about requests WireMock produces or replays, never about requests it matches. A webhook definition describes a call WireMock will send outward; a logged-request builder reconstructs a call the journal already recorded. Neither is a stub definition, which is why the method never fits where people expect it to.

Why the confusion is worth naming

The failure is not random. It has three reliable sources, and recognising which one you are looking at speeds up the fix:

Habit carried from another stub server. In a product where the method is a predicate on a request model, withMethod( beside a path predicate is the natural shape, and the muscle memory survives the switch.
IDE completion. The name resolves in a WireMock codebase, so a search or a completion popup appears to confirm the guess before the type error contradicts it.
Over-correction. Having been told withMethod( is not the matching API, people sometimes conclude it does not exist in WireMock at all. It does — on two classes that have nothing to do with matching — and asserting its non-existence is its own error.

Practical consequences

Do not look for a method predicate in a WireMock stub. If the first line does not say the verb, the stub does not constrain it.
Reach for any( rather than writing the same URL matcher out once per verb, when the method genuinely is not a criterion.
Reserve requestMatching( for conditions the built-in predicates cannot state, and remember that an inline matcher written in Java does not round-trip into a JSON stub mapping unless it is registered as a named custom matcher extension.
When reviewing a stub set that draws on more than one stub server, check the DSL shape before the identifier: a withMethod( sitting beside a path predicate is a sign the mapping was written in another product's idiom.

The rule to remember is short. In WireMock, the verb is the first thing you write and the only place it can go; withMethod( is a real WireMock name that belongs to two builders on the far side of the request lifecycle.

## The method lives in the builder, not in a predicate Most of a WireMock request pattern is built by chaining predicates — a URL matcher, header matchers, body matchers. The HTTP method is the exception. It is fixed by the *static factory that opens the pattern*, and there is no separate call that sets it afterwards. So a bookbindery order stub is written as `stubFor(post(urlPathEqualTo("/bindery/v2/orders")))`, and the word `post` is the entire method criterion. There is nothing to add and nothing that could contradict it later in the chain. That is a deliberate design: because the method is chosen first, every WireMock stub has exactly one method criterion or none, and it is visible on the first line of the mapping. ## The builders you actually use - WireMock's `get(`, `post(`, `put(`, `delete(`, `patch(`, `head(`, `options(` and `trace(` each open a pattern with that one method fixed, and each takes a URL matcher as its argument. - WireMock's `any(` opens a pattern with **no** method constraint while still applying the URL matcher you hand it, so `any(urlPathEqualTo("/bindery/v2/orders/BND-4417"))` answers every verb aimed at that one path. - WireMock's `requestMatching(` steps outside the fixed set entirely and hands the whole request to a matcher you write, for criteria no built-in predicate expresses. Because the URL matcher is the builder's argument rather than a sibling call, the two axes compose cleanly: `get(urlPathTemplate("/bindery/v2/orders/{orderId}"))` reads as *this verb, that path shape*, and neither half can be changed without touching the other's slot. ## Where withMethod actually lives This is the trap the question is really about, and it is a genuine one because the name exists and autocompletes. | Name | Product | Where it lives | What it does | |---|---|---|---| | `get(`, `post(`, `any(` | WireMock | the `WireMock` static factories | opens a request pattern with the method fixed or free | | `requestMatching(` | WireMock | the `WireMock` static factories | opens a pattern backed by a matcher you supply | | `withMethod(` | WireMock | `WebhookDefinition`, `LoggedRequest.Builder` | sets the method of an outbound webhook, or of a request reconstructed from the journal | | `withMethod(` | MockServer | the request model of an expectation | the method predicate of a MockServer expectation, paired with `withPath(` | The two WireMock homes for `withMethod(` are both about requests WireMock *produces or replays*, never about requests it *matches*. A webhook definition describes a call WireMock will send outward; a logged-request builder reconstructs a call the journal already recorded. Neither is a stub definition, which is why the method never fits where people expect it to. ## Why the confusion is worth naming The failure is not random. It has three reliable sources, and recognising which one you are looking at speeds up the fix: 1. **Habit carried from another stub server.** In a product where the method is a predicate on a request model, `withMethod(` beside a path predicate is the natural shape, and the muscle memory survives the switch. 2. **IDE completion.** The name resolves in a WireMock codebase, so a search or a completion popup appears to confirm the guess before the type error contradicts it. 3. **Over-correction.** Having been told `withMethod(` is not the matching API, people sometimes conclude it does not exist in WireMock at all. It does — on two classes that have nothing to do with matching — and asserting its non-existence is its own error. ## Practical consequences - Do not look for a method predicate in a WireMock stub. If the first line does not say the verb, the stub does not constrain it. - Reach for `any(` rather than writing the same URL matcher out once per verb, when the method genuinely is not a criterion. - Reserve `requestMatching(` for conditions the built-in predicates cannot state, and remember that an inline matcher written in Java does not round-trip into a JSON stub mapping unless it is registered as a named custom matcher extension. - When reviewing a stub set that draws on more than one stub server, check the DSL shape before the identifier: a `withMethod(` sitting beside a path predicate is a sign the mapping was written in another product's idiom. The rule to remember is short. In WireMock, the verb is the first thing you write and the only place it can go; `withMethod(` is a real WireMock name that belongs to two builders on the far side of the request lifecycle.

In WireMock, what does requestMatching() buy you that the method builders cannot?
It hands the whole request to a matcher you supply, so criteria no built-in predicate expresses — a relationship between the path and a header, for instance — become sayable. The cost is that the logic is code rather than a declarative pattern, so it is harder to read in review, and an inline Java matcher does not round-trip into a JSON stub mapping unless you register it as a named custom matcher extension.
Where does WireMock's withMethod actually appear, and why does that matter?
On `WebhookDefinition`, where it sets the method of an outbound webhook WireMock itself sends, and on `LoggedRequest.Builder`, which reconstructs a request the journal recorded. Both concern requests WireMock produces or replays rather than requests it matches. That is precisely why the name autocompletes in an IDE and then refuses to fit a stub definition — the guess looks confirmed right up to the type error.

saying these in an interview costs you the question

Calling withMethod( WireMock's method-matching predicate
Concluding withMethod( does not exist in WireMock at all
Thinking any( relaxes the URL as well as the method
Expecting a method name inside urlEqualTo to constrain the verb
Assuming requestMatching( takes an HTTP method name

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

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The method lives in the builder, not in a predicate

The builders you actually use

Where withMethod actually lives

Why the confusion is worth naming

Practical consequences

▾common follow-ups2 questions

▾red flags5 flags

The method lives in the builder, not in a predicate

The builders you actually use

Where withMethod actually lives

Why the confusion is worth naming

Practical consequences

answer

go deeper