Feature Request: Access response body for Error responses

[SeanLMcCullough]

Content & configuration

Swagger/OpenAPI definition:
N/A - documented issue

Swagger-Client usage:
N/A - documented issue

Is your feature request related to a problem?

My apologies if this is a raised and closed issue. I could not find any prior issues in the repo from a bit of searching though.

The response body is not accessible for error responses (where res.ok is not true). This is a problem for web APIs that provide useful information such as validation messages that could be useful to the client. Swagger/OAS also allows error responses to be defined. This means that these responses are not useful when using swagger-js

The documentation for swagger-js mentions

HTTP Client will reject all responses with ok field set to false - status outside of the range 200-299. This is another distinction from standard Fetch API.

The current implementation follows:

  if (!res.ok) {
    const error = new Error(res.statusText || `response status is ${res.status}`);
    error.status = res.status;
    error.statusCode = res.status;
    error.response = res;
    throw error;
  }

Describe the solution you'd like

Due to breaking backward compatibility, I would assume it is not possible to make swagger-js behave the same as Fetch, in that it will not throw on a non-ok response. I would suggest that this is made configurable at least on a global or per-request basis to skip the behaviour of throwing if the response is not ok. Alternatively, the ability to configure the status code range for errors to be thrown could be desirable.

An alternative could be to include the entire response and/or request with the error. This could be a good solution because it is the same tack that the Axios team have taken.

e.g.

try {
  await api.Things.getThingById({ id: 1 })
} catch (e) {
  if (!e.ok && ('response' in e)) {
    const body = await e.response.json()
    // do something with body
  }
  else throw e
}

Another alternative could be to include res.body or res.json from the original response as part of the error.

e.g.

try {
  await api.Things.getThingById({ id: 1 })
} catch (e) {
  if (!e.ok && ('body' in e)) {
    // do something with e.body
  }
  else throw e
}

Describe alternatives you've considered

One workaround I have attempted is using a response interceptor to set ok to true for all responses to bypass the behaviour. It is also misleading and could be a footgun. This would be a global change in my application and will break all existing usages. The interceptors only receive the request or response, and I am unsure if there is an elegant way of embedding an option to bypass the ok check that will be available in the response interceptor on a per-request basis.

Additional context

https://developer.mozilla.org/en-US/docs/Web/API/fetch#examples

https://swagger.io/docs/specification/describing-responses/#status-codes

https://axios-http.com/docs/handling_errors