return HttpResponseMessage when there is no return type

[vmachacek]

First of, great tool, I love it, and save me a lot of typing.

When response type cannot be detected could this tool make Refit return HttpResponseMessage ?

[Dreamescaper]

I was planning to add an option to use ApiResponse return type, so you'd be able to get response info for any request. That would affect all API methods though, not void only.

Could you clarify your use case? Why do you need response info for void methods, but don't care about that for non-void methods?

[vmachacek]

I'm using it for generating clients for testing purposes. When I'm getting data form the API, that is enough for test assertions. But when I'm sending commands to the API the response is always IActionResult so in this case it would be beneficial to get something I can do assertion on - also http status code is important for assertion. Also it would be beneficial to create just one file for whole API and add comment this was generated by this tool etc.. So anyone visiting the file would get how it works

[Dreamescaper]

So you need that to validate that response has successful status code, right? Refit has the default behavior to throw an exception if the response status code is not successful (i.e. non 2**). Do you need to validate anything on top on that?

[vmachacek]

Catching exceptions is alright, but making assertions on response code feels cleaner when testing.

[vmachacek]

I have new need for this again - that is when tool cannot determine the return type of API it would be cool if it would fallback to Task instead of Task. Certainly not for all methods, just as a fallback..

I can take a look and make a PR..

[vmachacek]

I made this adjustment in my fork - would you be willing to accept it as a PR?

https://github.com/Dreamescaper/GenerateAspNetCoreClient/commit/16d1a0d05553e2d56e2a9190c670e1dc012600d9

[Dreamescaper]

Unfortunately, it's not that straightforward. Refit disables status code validation for methods with HttpResponseMessage return type: https://github.com/reactiveui/refit/blob/main/Refit/RequestBuilderImplementation.cs#L261

And I'm not sure even if it makes sense to make it configurable - because that would make this behavior inconsistent, you'll have default validation for void methods and no validation for non-void validation.

I was planning to add a switch to generate Task<ApiResponse<T>> instead of Task<T> and Task<ApiResponse> instead of Task. Maybe that would help, as you can access original request message via ApiResponse object.

I'm curious, though - in which cases tool cannot determine the return type?

[vmachacek]

I like the idea with ApiResponse. To your question: it's when the controller method have either void, Task, ActionResult or IActionResult. I was not able to find anything unusual.

[Dreamescaper]

I've published updated version to nuget, please check it out. I've added an option --use-api-responses to use IApiResponse / IApiResponse<T> for return types. https://www.nuget.org/packages/GenerateAspNetCoreClient.Refit/

[vmachacek]

awesome, love it, thanks!