🦋 Changeset detected

Latest commit: 0345a28

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

I think this is a breaking change, but one most seem to be in favor of. Love the direction of this so far! Please let us know if you need any assistance with passing tests, or have any questions.

Looking at #1970, I have been thinking about the "parse-as" problem a bit as well.

I'm wondering if it would make sense to make the parsing lazier. One issue I see with the current API is that the caller cannot look at the status code to decide on how to parse the response. I'm not sure this is very ergonomic.

For example, it is very possible that an API returns a binary stream on 200, but a JSON response on other error codes. In this case, being able to specify parseAs only individually might not be sufficient.

One way to work around this problem is to provide accessors:

const resp = client.GET("/thing");

if (resp.status == 200) {
  resp.stream()
} else {
  resp.json()
}

This is somewhat inspired by requests.

I realize

• this wouldbe a major change
• we need to be careful about the performance implications of the potentially additional wrapper we'd need

However, I fear if we go down the "pass parseAs parameter path", we'll get more and more complicated options (e.g. parseAs per response code, etc.).