The Fetch API's Request Object
The Fetch API's Request object is a blueprint for an HTTP call, bundling URL, method, headers, and body. It's key for intercepting traffic in service workers or building reusable fetches. The main footgun: its body is a stream that can only be read once.
Why it exists
Before the Fetch API, XMLHttpRequest handled requests with a mix of properties and methods on a single stateful object. The Request object provides an immutable, more predictable representation of an HTTP request, making it easier to pass around, inspect, and manage, especially in asynchronous contexts like service workers.
The mental model
A Request object is like a sealed envelope containing a letter. The envelope has the address (url), postage instructions (cache, credentials), and return address (referrer). The letter inside is the body. You can't change the envelope once it's sealed (it's immutable), and you can only read the letter once. If you need another copy, you have to photocopy it using the clone() method.
How it works
A Request object is a core part of the Fetch API. You can create one explicitly using its constructor: new Request('/api/data', { method: 'POST', body: '...' }). More commonly, you'll receive a Request object from an event, like event.request inside a service worker's 'fetch' event listener. The object has read-only properties like method, url, and headers (which is a Headers object). The body property is a ReadableStream. To access its contents, you use methods like request.json(), request.text(), or request.blob(), which return promises that resolve with the body's content.
When to use it
Use the Request object when you need to intercept and programmatically handle network requests, which is the primary use case in service workers for caching or offline support. It's also useful for creating complex, pre-configured requests that you might want to send multiple times (after cloning) or pass to different functions.
When not to use it
For simple GET requests where you only need the URL and don't need to configure headers, credentials, or other options, passing a URL string directly to fetch() is simpler: fetch('/api/user'). Creating a full Request object for this would be overkill. It's also not needed if you're working with older APIs that rely on XMLHttpRequest.
One canonical example
In a service worker, you can intercept an outgoing request to implement a cache-first strategy. The fetch event listener receives an event where event.request is the Request object. You can log its method and URL (request.method, request.url), then use it as a key to check a cache with caches.match(request). If a match is found, you serve the cached response; otherwise, you pass the original request object to fetch() to get it from the network.
Interview question
When handling a Request object in a service worker, why is it often necessary to call request.clone() before using it in multiple operations?
- a.To ensure that the request's body stream can be read independently by each operation.Correct
- b.To allow modification of the request's URL or headers for different operations.
- c.To prevent the original Request object from being garbage collected after its first use.
- d.To create a deep copy of the request, including its associated response, for caching purposes.
Why? this is the answer
The Request object's body is a ReadableStream that can only be consumed once. Cloning creates a new Request object with an independent, unread copy of the body stream, allowing it to be used by multiple consumers like caches.match() and fetch(). Option B is incorrect because Request objects are immutable; cloning does not allow modification of properties like URL or headers.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles