Open rwwilden opened 3 years ago
Ok, I think I found the objection to doing this :)
ApiException
depends on HttpResponseMessage
which isn't exposed in IApiResponse
. Exposing that would probably mean a major departure from what Refit attempts to accomplish?
Before I create a PR I'd like to know if there's any objection to doing this that I might overlook. I just switched to 6.x and ran into this issue.
Is your feature request related to a problem? Please describe. For unit testing scenarios it would be much easier if my methods exposed
IApiResponse<T>
instead ofApiResponse<T>
. It would make mocking the response a lot easier.However, at quite a few locations I call
EnsureSuccessStatusCodeAsync
on the return value of API calls. This only exists onApiResponse<T>
, meaning it's impossible to switch all my methods toIApiResponse<T>
.Describe the solution you'd like Pull
EnsureSuccessStatusCodeAsync
into theIApiResponse<T>
interface.Describe alternatives you've considered Leave as is, making my unit tests a little more convoluted because creating an
ApiResponse<R>
there now also requires aRefitSettings
.Describe suggestions on how to achieve the feature PR to pull method into interface plus maybe a couple tests (haven't looked into that).