Description
Description
The current implementation handles all of the !response.ok
cases by putting the response body into the error
field. This makes it impossible to distinguish whether it was a 404 error (a legitimate case when the resource is not found) or some other error (i.e. a 500 error). In the first case I want to show the user a "Item not found" message, while in the other cases I probably want to show a "Error fetching the data" message and maybe log the error so that it can be fixed. Now I can only distinguish these cases by checking the content of the response, but this might be unsolvable in cases where the BE does not provide any general response for 404 responses that can be relied on.
The only workaround I found is to implement an openapi-fetch
middleware and wrap the status code into the response. But this makes the expected response TS type differ from the actual enhanced type, which is quite painful.
Proposal
I am not sure what the best solution might be. The error
could be an "enhanced" response body: error: { responseBody: ResponseType; responseStatus: number; }
. But this introduces a nasty BC break which is probably not justifiable. Maybe if there was a configuration option to opt in for this behavior? I don't like this kind of configuration options either...
Extra
- I’m willing to open a PR (see CONTRIBUTING.md)