Some thoughts on CallWebApiForUserAsync2<TInput, TOutput>

I have switched some existing code to use IDownstreamWebApi which is great…

In the end I i knocked together the following so the app could access an existing API

public static async Task<TOutput> CallWebApiForUserAsync2<TInput, TOutput>(this IDownstreamWebApi downstreamWebApi, string optionsInstanceName, TInput input, Action<DownstreamWebApiOptions> downstreamWebApiOptionsOverride = null, ClaimsPrincipal user = null)
        {
            HttpResponseMessage response = await downstreamWebApi.CallWebApiForUserAsync(
                optionsInstanceName,
                downstreamWebApiOptionsOverride,
                user,
                new StringContent(JsonSerializer.Serialize(input), Encoding.UTF8, "application/json")
                ).ConfigureAwait(false);

            try
            {
                response.EnsureSuccessStatusCode();
            }
            catch
            {
                string error = await response.Content.ReadAsStringAsync().ConfigureAwait(false);

                throw new HttpRequestException($"{(int)response.StatusCode} {response.StatusCode} {error}");
            }

            string content = await response.Content.ReadAsStringAsync().ConfigureAwait(false);

            if (string.IsNullOrWhiteSpace(content))
                return default;

            return JsonSerializer.Deserialize<TOutput>(content, new JsonSerializerOptions { PropertyNameCaseInsensitive = true });
        }

1. Current CallWebApiForUserAsync only accepts OK status code
2. Current CallWebApiForUserAsync seems to not be able to accept Ok() returned from webapi i.e. blank string
3. Current CallWebApiForUserAsync only accepts TOutput as class so no OK(332)

I imagine IDownstreamWebApi might be still a work in progress?.. be great to hear how best to utilize it.

[jmprieur]

Thanks @parwejp these are fair points. Would you mind opening a new issue with this?

[parwejp]

@jmprieur : I am no expert, but according to .NET microservices - Architecture e-book HttpMessageHandlers are pooled, not HttpClient. The document encourages the use of IHttpClientFactory as provided by Typed Clients, described as

… just an HttpClient that’s pre-configured …[with some] … specific values such as the base server, HTTP headers or time outs.

Of course, DownstreamWebApi is just such a typed client.

The document also encourages the use of DelegatingHandlers for fine tuning requests on the way out and in. It also has a reference to Make HTTP requests using IHttpClientFactory in ASP.NET Core describing the pattern in more detail.

To be able to do this, though, one needs access to the IHttpClientBuilder returned from AddHttpClient.

In a production app, one would most likely write a dedicated typed client in any respect. However, providing a way to configure and add handlers to DownstreamWebApi would, together with the suggestions above, make it more flexible.

Maybe an overload of AddDownstreamApi that accepts Action<IHttpClientBuilder> would do the trick?

What do you think?

@jennyf19 : I am not able to find out how to send request headers while using get requests on iDownStreamWebAPI. I recently got an error while calling MS graph api to add “ConsistencyLevel = eventual” header. Microsoft Graph advanced queries Header Have switched to ITokenAquisition implementation for now but would be nice to use IDownStreamWebAPI for it. As @rollandjb mentioned it would be possible to set request headers with pooled HttpClient with proper isolation. I am no expert but creating HttpRequestMessage could be quick fix. If it is implemented already, could you please be kind enough to point me out to documentation?

Many Thanks