In Mock Service Worker (MSW) v2 a request handler is written as http.get('/api/users', resolver). What are the two halves of that handler, what must the resolver return, and does the component's own fetch() code have to change?

## The shape of a handler A Mock Service Worker handler is a small declarative object created by a factory. In MSW v2 the factories live in two namespaces: `http` for REST-style requests (`http.get`, `http.post`, `http.put`, `http.patch`, `http.delete`, and `http.all` for any method) and `graphql` for GraphQL operations. Every factory call takes a predicate and a resolver: ```js import { http, HttpResponse } from 'msw' export const handlers = [ http.get('/api/users', () => { return HttpResponse.json([{ id: 1, name: 'Ada' }]) }), ] ``` The first argument — method plus path — is the predicate. The second is the resolver. ## The predicate half The predicate decides *whether this handler claims the request*. `http.get('/api/users')` claims only GET requests whose URL matches that path; a POST to the same path falls through to another handler or to the unhandled-request policy. Paths support named parameters, written with a colon: `http.get('/api/users/:id')` matches `/api/users/7` and hands the resolver `params.id === '7'` (always a string — parse it if you need a number). You can also write a full absolute URL, which is what you want when the app talks to a different origin, e.g. `http.get('https://api.example.com/users', …)`. Matching is per handler, in order: MSW walks the handler list and the first handler whose predicate matches resolves the request. That means a broad pattern placed first can shadow a specific one placed later, which is one of the more common self-inflicted bugs when a mock "doesn't work". ## The resolver half The resolver is an ordinary function — it may be async — that MSW invokes with an object describing the intercepted request. The fields you reach for most are `request` (a standard `Request`, so `await request.json()` gives you the posted body and `new URL(request.url).searchParams` gives you the query string) and `params` (the named path parameters). Its return value must be a `Response`. MSW v2 ships the `HttpResponse` helper for building one without boilerplate: ```js http.post('/api/orders', async ({ request }) => { const body = await request.json() return HttpResponse.json({ id: 1, ...body }, { status: 201 }) }) ``` `HttpResponse.json(value, init)` sets the JSON content type and serialises for you; there are also `HttpResponse.text()`, `HttpResponse.xml()` and the plain `new HttpResponse(body, init)` form. Returning a bare JavaScript object does **not** work — this is the single biggest v1-to-v2 trap, because MSW v1 used a `(req, res, ctx) => res(ctx.json(...))` signature that no longer exists. A resolver may also decline to mock: returning the value from `passthrough()` tells MSW to let the request go to the real network, and returning `undefined` lets the next matching handler try. ## What the application sees The important consequence is negative: nothing. The component is not handed a fake client, `fetch` is not swapped for a spy, and no import is rewired. The application builds a real `Request` and hands it to the platform; MSW intercepts it below that point and produces a real `Response` object, which then flows back through the app's normal parsing, error handling and state updates. Response headers, status codes and body parsing all behave the way they would in production, so the code path under test is the shipped one. This also means the handler is described in the vocabulary of the API, not of your module graph. If the team renames its HTTP wrapper, moves from `fetch` to another client, or reorganises where the call is made, the handlers keep working, because the only contract they encode is method + URL + payload. ## Where handlers live Because a handler is just a value with no environment coupling, the convention is one `handlers.js` module exporting an array, imported by whichever setup the current environment needs. A test file adds or replaces individual handlers for its own scenario rather than rebuilding the list. Keep the shared array describing the *happy path* of each endpoint your app calls, and let each test express only the deviation it cares about. ## Common mistakes Forgetting the method (using `http.get` for an endpoint the app POSTs to), writing a relative path when the app calls an absolute cross-origin URL, returning a fixture object instead of a `Response`, and ordering a catch-all pattern ahead of the specific one it shadows. All four present identically — the request appears unmocked — so check the predicate before you suspect the tooling.