Fetch API Support Beta

[kettanaito]

Hey! Thank you for taking the time to help us with the next library release. We’re approaching this one as a release candidate because it contains quite a number of breaking changes.

• Feature proposal
• feat!: adopt the global Fetch API #1436

Motivation

The main motivation behind this release is to rework the public API to respect and use the Fetch API standard. This means handling intercepted requests as Request instances and expecting the mocked responses to be declared as Response instances. While this may sound simple, it requires a significant change to how MSW is used by each of you.

This is also the biggest API change we’ve had since the day I pushed the req, res, ctx API. With this release, that era is gone and so is that API. The next era begins and it looks fantastic.

Before you begin

The purpose of this beta release is to gather your feedback on the changes. We kindly ask you to share such feedback in the comments under this discussion, following these rules:

1. Please browse the existing comments below before posting yours. If you spot a similar topic, please leave a comment under it describing your more detailed case.
2. 1 post = 1 issue/topic. Please note that you can comment under your own post if you wish to provide additional info or respond to somebody’s comment.
3. Please be patient. This is a huge change, and we trust it to be our common goal to make it as smooth as possible for everyone.
4. Link reproduction repositories to reported issues. This will help us tackle the issues tremendously faster.

Getting started

👉 Please follow the Migration guide to learn more about how to install this beta release and the migration instructions for every feature we’ve changed or deprecated.

Expect breaking changes. It will require some effort to migrate any existing MSW setup to the new API but it’s going to be worth it.

What is expected from the participants?

• Report the things that the Migration guide failed to cover or covered insufficiently/incorrectly.
• Report the use cases which were troublesome to migrate.
• Share feedback on how to improve the migration guide.
• Report issues after migrating to the beta version.
• Share your opinion on the new API, its look and feel. Don’t be shy to share good feedback as well, if you’ve got any, we’ve worked hard on making this beta release happen.

---

Frequently asked questions

Are these changes backward-compatible?

No. Backward compatibility is beneficial when you want to have the advantage of the change while remaining on the previous API. This change, however, is about the API, so maintaining backward compatibility is not feasible for it. If you wish to use the previous API you can do so by staying on the previous version. However, you will update to these changes eventually as this is the public API we’re going forward with.

Are these changes “production” ready?

No. Be mindful that you’re trying out a beta release of the library. Things may and likely will change as we iterate through your feedback.

That being said, the API changes proposed in this release will end up in the public release, eventually. This is the direction we’re taking, so migrating to it may ease any additional changes you need to do in your setup once this release becomes public.

When is this release going to be public?

As soon as we gather enough feedback to be certain people can migrate to the new version without issues. We will then release the changes under the latest tag, updating the documentation respectively.

[elliotgonzalez123]

Greetings,

I started a fresh NextJs application, applied the new syntax to my handler, ran a simple test that checked for data after a GET request, and Jest blew up. If I switch back to the latest msw version and apply the old syntax, everything works as usual.

• Next v13.0.1
• axios v1.1.3
• Jest v28.1.0
• testing-library/react v13.4.0
• msw v0.0.0-fetch.rc-1
• Node v18.8.0

Handler:

export const handlers = [
  rest.get("https://catfact.ninja/fact", () => {
    return HttpResponse.json({ fact: "Hello", length: 4 });
  }),
];

Error:

Desktop/Dev/ci-cd-next/node_modules/@remix-run/web-fetch/src/lib.js:4
    export { ReadableStream, Blob, FormData  } from './package.js';
    ^^^^^^`

     SyntaxError: Unexpected token 'export'

      at Runtime.createScriptFromCode (node_modules/jest-runtime/build/index.js:1796:14)
      at Object.<anonymous> (node_modules/@mswjs/interceptors/src/interceptors/ClientRequest/utils/createResponse.ts:2:1)

[kettanaito]

This seems related to mswjs/interceptors#283 (review). @remix-run/web-fetch distributes in a format that not all apps may consume by default. We likely need to bundle that dependency as a part or @mswjs/interceptors.

[kettanaito]

Update

We've moved away from the Fetch polyfill and dropped Node.js < 18 support. This shouldn't be an issue anymore.

However, we don't currently have support for the latest Next (App router) and we likely won't have it until after v2.0 releases. It seems to be extremely Next-specific and I don't have the time capacity to look into it unless we team up with the folks from Next and achieve this together.

[committomaster]

It's probably worth mentioning the new Response.json() static method may be an alternative for MSW's HttpResponse.json(). There's also Response.redirect().

[committomaster]

Yes, I'm not against HttpResponse, and agree there are use cases that Response cannot cover. Just thought Response.json() might deserve a mention in the docs.

[kettanaito]

I think Response.json() is common knowledge. It's not the library's mission to teach you about Fetch API but rather to support you in using it. So, if you know Response.json() is a thing, you may try it in MSW. You may see we don't have it yet, and it may encourage you to read if it's a widely supported thing in general or not. Does this approach make sense to you?

[committomaster]

Fair enough. The docs mentioned that creating a JSON Response is too verbose, and I just wanted to point out that's not the case for much longer.

[kettanaito]

That's a fair point. Perhaps we should advocate for HttpResponse using a different argument than brevity.

[kettanaito]

Update

• Response.json() is great but it doesn't exist in node. Given this, we won't be mentioning it in the docs.
• We will list all examples in the docs using HttpResponse so it's easier for people to get started and not be confused about all the other recipes and suggestions we have. This is a sensible common ground (see my explanation above).

[committomaster]

From the migration guide:

Since Fetch API Headers do not support multiple values as the HeadersInit, to mock a multi-value response cookie create a Headers instance and use the .append() method to set multiple Set-Cookie response headers.

This is possible with an array of entries instead of a plain object:

new Headers([
  ["Set-Cookie", "sessionId=123"],
  ["Set-Cookie", "name=world"],
]);

[kettanaito]

I didn't know this one. Thanks for sharing, @committomaster! This is going straight to the docs.

[committomaster]

I think just passing the array to ResponseInit.headers should do the job. No need to manually instantiate Headers there.

[kettanaito]

A valid point. At this stage, the way people use ResponseInit.headers is common knowledge. I don't mind showcasing two examples: giving a plain object and giving a Headers instance.

[committomaster]

But the new Headers() part is redundant:

new Response(null, {
  headers: [
    ['Set-Cookie', 'sessionId=123'],
    ['Set-Cookie', 'gtm=en_US'],
  ],
});

[committomaster]

With all the breaking changes towards the standards, may I also suggest renaming rest to http? 😅

[committomaster]

My point was exactly that HTTP and REST are not interchangeable. What MSW calls rest is much more generic than REST as you said. It can be used to mock any HTTP API, including GraphQL APIs. Also, REST is just as protocol agnostic as GraphQL. It just happens to be most commonly used with HTTP, similarly to GraphQL. The difference is that GraphQL is a specification while REST is just a pattern.

[kettanaito]

I understand your point but see little value to do such a breaking change. The workflow here is to ask yourself what kind of API you're mocking:

• Okay, I want to mock a REST API, so I import rest;
• I want to mock a GraphQL API, so I import graphql.

There isn't really a thinking chain that goes: I want to mock a REST API, so I import http...

If this is semantically confusing, consider using an import alias:

import { rest as http } from 'msw'

[kettanaito]

Update

We will not be renaming rest to http. Although, this may change in the future as we introduce other protocols, like WebSocket. For now, rest remains rest.

[thepassle]

I dont mean to revive a zombie thread, but I kind of agree that http makes more sense than rest, not all requests are RESTful, but all RESTful requests are http requests. And even graphql requests are http requests 😅. Also at work we have some API's at work that are not RESTful.

I do see that its nice for a user to import graphql when you're mocking a graphql api (and I think you should keep that), but I do think it does make sense to rename rest to http. Whenever I need to mock a network request, my first thought is not "Is this a RESTful request?"

Especially when you're on the verge of making a breaking change, and you're considering to add something like WebSocket in the future anyway, I'd say the time is now; break away. In this case the breakage is pretty easily fixed by a simple find/replace any (rest. -> http.) anyway.

(and also IMO http.get('/api/foo', () => Response.json({})); is much nicer, but thats just personal preference 😛)

[kettanaito]

@thepassle, the more I think about this the more I think this may be a good step forward. http would stand for a protocol handlers while graphql would be a helper object. GraphQL is often done via HTTP in JavaScript, so it makes sense that you can mock a GraphQL operation using both graphql and http. If anything, I think it reads more nicely since GraphQL operations are not RESTful resources. Just as not all HTTP requests as RESTful resources, like you've rightfully pointed out.

I will roll out the change in the next release candidate. Thanks everyone for this discussion.

[dbritto-dev]

@kettanaito this is what I found implementing some tests -> https://codesandbox.io/p/sandbox/msw-standard-api-9z1f0h?file=%2Frest.spec.ts

Seems the Response instance from require('@remix-run/web-fetch') has a default content-type, the default value is text/plain;charset=UTF-8 I have no idea if that was intended or not but that's the reason of one the unit tests are failing. In the other hand HttpResponse is working as expected.

Note: I expected the same behavior as HttpResponse from Response

[dbritto-dev]

I tried in a Chromium based browser but I don't get that result for me is null

[committomaster]

If a response has any body, it's Content-Type will be text/plain.

There are also some conveniences built-in with the Response constructor, e.g. an instance of URLSearchParams as body sets the content type to application/x-www-form-urlencoded, or an instance of FormData sets the content type to multipart/form-data.

[kettanaito]

As we're using a third-party polyfill for these Fetch primitives, we delegate the responsibility to fulfill the specification to that polyfill. We won't be addressing behavior differences around this. But if there are any, I strongly encourage you to report them in https://github.com/remix-run/web-std-io/tree/main/packages/fetch.

[dbritto-dev]

That's Ok if that is the expected behavior from that package.

[kettanaito]

Update

We no longer depend on the Fetch polyfill and use the native Node.js Fetch API instead (based on Undici). I don't believe it has this issue.

[wKovacs64]

❤️ the new API. I tried it out in 3 projects and found myself just knowing what to do thanks to already knowing Request, Response, etc. rather than having to go look at MSW docs when I couldn't remember some context utility or whatever. Great job, looking forward to this being released!

The only frustration was not being able to use Node 18, but that applies to the current version of MSW as well so nothing new to report there.

[kettanaito]

Thanks for the feedback, @wKovacs64!

Yes, we don't have Node 18 support yet but I think there's an effort behind it. I'm certain that will happen one day.

found myself just knowing what to do thanks to already knowing Request, Response, etc. rather than having to go look at MSW docs

Expecting ads revenue from docs to drop 😄

[wKovacs64]

Yes, we don't have Node 18 support yet but I think there's an effort behind it. I'm certain that will happen one day.

I hope it's more urgent than "one day" as Node 18 is the active LTS (with 16 now in Maintenance). I'm unable to recommend/use MSW at work because of this, unfortunately. 😢

Expecting ads revenue from docs to drop 😄

😆

[kettanaito]

I've looked into the latest status on Node 18 support, and there's been a tremendous amount of work done by our contributors.

• Support Node.js v18 #1388

I see that the only thing pending is mswjs/interceptors#283, which, in itself, is complete but has issues with @remix-run/web-fetch being imported in Node 18. I hope that package supports Node 18 otherwise we're blocked.

If you have time, you could investigate an issue I'm having: mswjs/interceptors#283 (review). This also seems to be the very same issue reported above by @elliotgonzalez123.

[kettanaito]

Update

The latest release candidate for these changes supports Node.js 18+ and also ships with ESM support. A bright day on the modern tech street 🎉

npm install msw@next --save-dev

[xmlking]

I am testing with vitest here: https://github.com/xmlking/svelte-starter-kit/tree/main/src/mocks

env: node v18.11.0 , "cross-fetch": "3.1.5", "msw": "0.49.0" <--- Works
env: node v18.11.0 , "cross-fetch": "3.1.5", "msw": "0.0.0-fetch.rc-1" <--- Time out error

looking for any workaround or fix

[kettanaito]

Thanks for reporting this. This may be a bit hard to trace down since we don't officially support Node 18. Although the A/B you did with the public version seems to suggest the issue is in these new changes.

[kettanaito]

Now, as we ship Node.js 18 support, I'm going to look into this and see what's going on...

[kettanaito]

Okay, I see that the linked repo doesn't use the next version of msw.

@xmlking, I recommend taking a look at our new Examples suite that features a full Svelte integration. We haven't experienced any issues with Svelte + MSW during integration and E2E tests (and local development). Take inspiration from that example!

[christoph-fricke]

Love the upcoming changes! As already mentioned in #1436, I noticed a TypeScript bug when passing a predefined object to HttpResponse.json. I updated the original sandbox to include both synchronous and asynchronous examples as the problem appears in both: https://codesandbox.io/s/msw-next-i0eijp?file=/src/index.ts

[kettanaito]

Thanks for reporting this, @christoph-fricke! Will have to look into this one. Didn't spot any issues on the first glance. Something must be off with the response type inference. I suspected the async resolver to be the case but you're saying it's the same for the sync one too. I wonder how come our typings tests pass.

msw/test/typings/rest.test-d.ts

Lines 79 to 81 in 041ff3e

	rest.get<never, never, { id: number }>('/user', () => {
	return HttpResponse.json({ id: 1 })
	})

[christoph-fricke]

@kettanaito I find the problem really strange as well and don't really have a clue... I experimented a bit with the test you have linked.

It appears to work fine with previously created objects as expected:

rest.get<never, never, { id: number }>('/user', () => {
  const obj = { id: 1 };
  return HttpResponse.json(obj)
})

However, it fails once the type of obj is defined explicitly with an interface:

interface ID {
  id: number
}

rest.get<never, never, ID>('/user', () => { // <-- Fails here with a return error problem
  const obj: ID = { id: 1 };
  return HttpResponse.json(obj) // <-- Fails here with "Index signature for type 'string' is missing in type 'ID'"
})

Strangely, it works fine if the interface is replaced with a type:

type ID = {
  id: number
}

rest.get<never, never, ID>('/user', () => {
  const obj: ID = { id: 1 };
  return HttpResponse.json(obj)
})

[kettanaito]

Oh, I think this is a common issue when the expected generic type expects Record<string, unknown> but you provide an interface, which does not have an index signature type by default.

Temporarily, you can circumvent this by declaring your body type as a type, just as you did in the last example.

[christoph-fricke]

@kettanaito I think a found a simple fix for the problem, which can be found in the PR #1481.

[kettanaito]

Thank you so much for improving this release, @christoph-fricke! Merged.

[the-ult]

I'll repost my question regarding the new Beta and generics here:
@see: #1308 (comment)

What would be the proper way to use the Generics with the next MSWjs version?

• https://github.com/mswjs/msw/blob/feat/standard-api/MIGRATING.md#migration-guide
• https://dev.to/kettanaito/type-safe-api-mocking-with-mock-service-worker-and-typescript-21bf

What do you provide, when you don't have PathParams or a RequestBodyType. I'm mostly interested in providing the ResponseBodyType, cause I need the proper return Type.

Is this the correct way? (providing undefined feels a bit icky 🤔 😇 )

/**
   * Handle the requests for POPULAR Movies
   * @see: https://developers.themoviedb.org/3/movies/get-popular-movies
   */
//get: <PathParams<string>, RequestBodyType_2 extends DefaultBodyType, ResponseBodyType_2 extends DefaultBodyType = undefined>
  rest.get<{ movieId: string }, undefined, MovieDetail | MovieError>(
    'movie/:movieId',
    ({ params }) => {
      const movieId = +params['movieId'];

      if (movieId === 436_270) {
        return HttpResponse.json<MovieDetail>(BlackAdam);
      }

      if (movieId === 505_642) {
        return HttpResponse.json<MovieDetail>(WakandaForever);
      }

      return HttpResponse.json<MovieError>({
        status_code: 56,
        status_message: `Movie with ID: ${movieId} not found`,
      });
    }
  ),

N.B.

• WakandaForever and BlackAdam are JSON files, with slightly different content.

Would the proper way be like the above replies? Using never ?

Or maybe using something like <T = void> or using function overloading, so not all generics are required?

https://garbagevalue.com/blog/optional-generic-typescript

[kettanaito]

Update

The type signature of request handlers remains as follows:

type Handler<ParamsType, RequestBodyType, ResponseBodyType> =
  (p: ParamsType, reqBody: RequestBodyType, resBody: ResponseBodyType>): RequestHandler<...>

To annotate the request and response body types you use it like this:

import { rest } from 'msw'

rest.get<never, RequestBody, ResponseBody>('/resource', () => {})

The latest release candidate msw@next should come with proper type inference already.

You use never when you don't wish to annotate request path parameters. You can also use void.

[the-ult]

Looks like with the latest version: "msw": "0.0.0-fetch.rc-3", Cypress (12.0.2) gives an error:
(version "msw": "0.49.1" does not give an error)

Error: Webpack Compilation Error
.../angular-nx-playground/node_modules/.pnpm/@remix-run+web-fetch@4.3.2/node_modules/@remix-run/web-fetch/src/fetch.js 120:13
Module parse failed: Unexpected token (120:13)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
| 			}
| 
> 			response_?.emit("error", err);
| 		});
| 
 @ .../angular-nx-playground/node_modules/.pnpm/@remix-run+web-fetch@4.3.2/node_modules/@remix-run/web-fetch/src/lib.node.js 1:0-72 1:0-72 1:0-72 1:0-72 1:0-72 1:0-72
 @ .../angular-nx-playground/node_modules/.pnpm/msw@0.0.0-fetch.rc-3_typescript@4.8.4/node_modules/msw/lib/index.js
 @ .../angular-nx-playground/libs/shared/test/msw/src/lib/server/server.ts
 @ .../angular-nx-playground/libs/shared/test/msw/src/lib/server/index.ts
 @ .../angular-nx-playground/libs/shared/test/cypress/src/lib/msw/msw.command.ts
 @ .../angular-nx-playground/libs/shared/test/cypress/src/index.ts
 @ ./src/e2e/movies-page.cy.ts
    at Watching.handle [as handler] (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/packages/server/node_modules/@cypress/webpack-preprocessor/dist/index.js:231:23)
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/webpack/lib/Watching.js:99:9
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/tapable/lib/Hook.js:154:20)
    at Watching._done (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/webpack/lib/Watching.js:98:28)
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/webpack/lib/Watching.js:73:19
    at Compiler.emitRecords (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/webpack/lib/Compiler.js:499:39)
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/webpack/lib/Watching.js:54:20
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/webpack/lib/Compiler.js:485:14
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/tapable/lib/Hook.js:154:20)
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/webpack/lib/Compiler.js:482:27
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/neo-async/async.js:2818:7
    at done (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/neo-async/async.js:3522:9)
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/tapable/lib/Hook.js:154:20)
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/webpack/lib/Compiler.js:464:33
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/packages/server/node_modules/graceful-fs/graceful-fs.js:143:16
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/packages/server/node_modules/graceful-fs/graceful-fs.js:143:16
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/packages/server/node_modules/graceful-fs/graceful-fs.js:61:14
    at FSReqCallback.oncomplete (node:fs:197:23)

[kettanaito]

Thanks for reporting this.

This may be related to the bundling of @remix-run/web-fetch. We have some work done on that on the Node side, I expected it to use browser globals in the browser. This needs looking into.

[the-ult]

Application and Jest tests (with testing-library-angular) work without a problem. Only the Cypress tests seem to fail (while loading).

Tried to debug, but could not really find anything other than that it must be related to "@remix-run/web-fetch": "^4.3.0", in the new package.json

[kettanaito]

Update

We no longer depend on the Fetch polyfill. This issue should be solved on the latest release candidate msw@next.

[nickrttn]

Hi folks! I've been using the Fetch API support to set up mocking for a mature codebase for the last week or so and it's been great. Use cases include a lightweight E2E testing suite that catches the most egregious errors, as well as a light weight development environment for our designers. It's a lot more intuitive than the previous iteration and it works really well. Two things that stood out to me and I wanted to point out to you:

• Currently, when I'm working on MSW handlers in development mode (we're still on webpack-hot-middleware), and I save, I get errors about already consumed Response bodies (Uncaught (in promise) TypeError: Response.clone: Body has already been consumed.) originating from serializeResponse. A hard refresh fixes those. Is this just a quirk of running MSW in a service worker or should this not be happening?
• Then, I have a need to set cookies and it would be great to have some sort of API for that. I really appreciate things being as close to 'platform-native' as they can be. However, the current API of writing out the bare header for Set-Cookie is pretty tricky to use.

[kettanaito]

Hey, @nickrttn! Thank you so much for your feedback.

I think the HMR bug is triggered by the handlers' code being re-evaluated upon HMR. Would be great to look into that. Would you mind isolating your dev setup (or creating a minimal one based on yours) for me to look at?

Regarding response cookies, you can use third-party libraries to help you compose cookie strings:

import cookie from 'cookie'

return HttpResponse.text('hello', {
  headers: {
    'Set-Cookie': cookie.serialize('token', 'value', {
      httpOnly: true,
      maxAge: 356000
    })
  }
})

I'm not planning on adding any cookie-related utilities in the nearest future.

[nickrttn]

Hey @kettanaito!

Thanks for your swift response :)

Would you mind isolating your dev setup (or creating a minimal one based on yours) for me to look at?

I'm working on a project with some legacy and a fairly complex setup, so I'll give it a try but it might be a while!

I'm not planning on adding any cookie-related utilities in the nearest future.

This is what I suspected, and understandable! I'll take a look at some third-party options.

[WesleyYue]

The Fetch API spec explicitly bans body on GET requests, despite this being quite common in the wild (and not explicitly banned by the HTTP spec). Stripe, Elasticsearch and many others all have API designs that require body in GET requests. node-fetch, axios also allows this.

[kettanaito]

No worries. We're all here to learn.

I will take a look at that Stripe example, thanks for putting that up.

[kettanaito]

I looked into the Stripe API briefly, and here's the implementation of GET /v1/prices:

https://github.com/stripe/stripe-node/blob/301f41df89169f49cd7b704adf1eaed6f903668c/lib/resources/Prices.js#L18-L22

At the top, you can see the mention that the implementation is generated from their OpenAPI spec. Let's dig that out. Here's the spec for GET /v1/prices (I'll highlight the relevant parts, the spec is rather verbose):

  /v1/prices:
    get:
      description: <p>Returns a list of your prices.</p>
      operationId: GetPrices
      parameters: 
        - description: >-
            A limit on the number of objects to be returned. Limit can range
            between 1 and 100, and the default is 10.
          in: query
          # Here's the "-d limit=3" parameter
          name: limit 
          required: false
          schema:
            type: integer
          style: form
      # And here's the specification for this request's body.
      requestBody:
        content:
          application/x-www-form-urlencoded:
            encoding: {}
            schema:
              additionalProperties: false
              properties: {}
              type: object
        required: false

You can see that the limit is listed as a parameter. More on that, it's defined as a query parameter (in: query). As I suspected, you don't send any body to this method, you include its data in request's query parameters!

So here's how you use that API correctly according to the Stripe API docs:

GET https://api.stripe.com/v1/prices?limit=3

At the same time, the requestBody of GET /v1/prices is explicitly stated to be a type: object with no properties (properties: {}) and no additional properties allowed. In human language, this means the body must be never present.

[WesleyYue]

As I suspected, you don't send any body to this method, you include its data in request's query parameters!

That makes sense to me. In that case, do you have any clue why interceptor raises the typeerror for that call then? If you run the codesanbox, you get this:

[dbritto-dev]

@WesleyYue shouldl works without any issues but may something goes wrong. Here is the code -> https://github.com/stripe/stripe-node/blob/master/src/makeRequest.ts#L66. May since we are intercepting the request a passing the response directly that is throwing an error. Ref: https://github.com/stripe/stripe-node/blob/master/src/StripeResource.ts#L198