Response Type changes base on return type
See original GitHub issueThe generated code changes the response type base on the return type of the method. This might have some secret reason, but produces a very hard to find error when working with the generated service. In my case (see below) it cause the err.error property to be a string, instead of a javascript object (json) and made the whole error handling code fail silently, just because the return type in the asp.net core WebApi changed. Ofcorse changing the return type causes the response handling code to have to change, but it is unintuitive that the error handling code should change. What makes the issue worse, is that there are numerous points of failure for an issue like that: the asp.net api, swagger/open-api documentation generation, ng-openapi-gen configration files or even IIS settings. Took me a very long time to find the issue.
I think this behavior should be changed, but for my case having a way to set the default response type used for the whole api would have been sufficient as I only want to use json anyway. My current workaround is just to return the ‘0’ to get a json response …
Note: The actual namespace and Dto class name was changed in the following code per company policy.
[HttpPost("save", Name = nameof(Save))]
public async Task Save(Dto dto)
{
var settings = dto.ToModels(tenant);
await _userSettingsRepository.Update(settings);
}
The code above produces
save$Response(params?: {
body?: Dto
}): Observable<StrictHttpResponse<void>> {
const rb = new RequestBuilder(this.rootUrl, DtoService.SavePath, 'post');
if (params) {
rb.body(params.body, 'application/*+json');
}
return this.http.request(rb.build({
responseType: 'text',
accept: '*/*'
})).pipe(
filter((r: any) => r instanceof HttpResponse),
map((r: HttpResponse<any>) => {
return (r as HttpResponse<any>).clone({ body: undefined }) as StrictHttpResponse<void>;
})
);
}
while the code
[HttpPost("save", Name = nameof(Save))]
public async Task<int> Save(Dto dto)
{
var settings = dto.ToModels(tenant);
await _userSettingsRepository.Update(settings);
return 0;
}
produces:
save$Response(params?: {
body?: Dto
}): Observable<StrictHttpResponse<number>> {
const rb = new RequestBuilder(this.rootUrl, DtoService.SavePath, 'post');
if (params) {
rb.body(params.body, 'application/*+json');
}
return this.http.request(rb.build({
responseType: 'json',
accept: 'text/json'
})).pipe(
filter((r: any) => r instanceof HttpResponse),
map((r: HttpResponse<any>) => {
return (r as HttpResponse<any>).clone({ body: parseFloat(String((r as HttpResponse<any>).body)) }) as StrictHttpResponse<number>;
})
);
}
Issue Analytics
- State:
- Created 2 years ago
- Comments:6 (3 by maintainers)
Top GitHub Comments
It is as expected. Unfortunately, there’s no way to specify distinct responseTypes for distinct HTTP status codes. The way we do a general error handling is like this: https://github.com/cyclosproject/cyclos4-ui/blob/0adeed887f8b397fa709d872a864df342df37f4c/src/app/core/error-handler.service.ts#L151 We just assume the error can be either a JSON object or a string.
Thanks for responding so quick and giving me an example of what your other project does.
After looking around online I understand why it can’t be done because of an Angular HttpClient restriction which seems obvious now.
For anyone else who revists this issue here are Angular issues that are related: