Add support for System.Net.Http.Json GetFromJsonAsync methods

[eduherminio]

It would be awesome to be able to wrap with Polly this call:

await _httpClient.GetFromJsonAsync<A>("relative_url", jsonSerializerOptions, cancellationToken);

Currently I haven't found a better way stop using GetFromJsonAsync extension method:

var response = await _retryPolicy.ExecuteAsync(async (_) => await _httpClient.GetAsync("relative_url", cancellationToken), cancellationToken);

return JsonSerializer.Deserialize<A>(await response.Content.ReadAsStringAsync(cancellationToken), jsonSerializerOptions);

---

The simplest solution I could thing of is adding overrides to all GetFromJsonAsync methods found here with a PolicyWrap parameter?
Although we would be executing the serialization part inside of the PolicyWrap.Execute(...) method, not sure how dumb is that.,

Sample:

public static partial class HttpClientJsonPollyExtensions
{
    internal const string SerializationUnreferencedCodeMessage = "JSON serialization and deserialization might require types that cannot be statically analyzed. Use the overload that takes a JsonTypeInfo or JsonSerializerContext, or make sure all of the required types are preserved.";
    internal const string SerializationDynamicCodeMessage = "JSON serialization and deserialization might require types that cannot be statically analyzed. Use the overload that takes a JsonTypeInfo or JsonSerializerContext.";

    [RequiresUnreferencedCode(SerializationUnreferencedCodeMessage)]
    [RequiresDynamicCode(SerializationDynamicCodeMessage)]
    public static Task<object?> GetFromJsonAsync(this HttpClient client, PolicyWrap policy, [StringSyntax(StringSyntaxAttribute.Uri)] string? requestUri, Type type, JsonSerializerOptions? options, CancellationToken cancellationToken = default)
    {
        return policy.Execute(() => client.GetFromJsonAsync(requestUri, type, options, cancellationToken));
    }

    // ...

}

[martincostello]

Have you looked into using HttpClientFactory with Polly? That plugs Polly v7 into any HTTP request, not just ones using the method for getting JSON.

There will be further new APIs for integrating Polly v8 into HTTP pipelines coming from the .NET team via the https://github.com/dotnet/extensions repository as part of the .NET 8 release later this year.

[eduherminio]

IMHO as far as the recommendation is not to use IHttpClientFactory for long-lived clients (as in HttpClient lifetime management), it would be beneficial to have the proposed extensions.

[martincostello]

If you don't want to use HttpClientFactory, then you could still use the delegating handler that wraps calls with Polly from the Microsoft.Extensions.Http.Polly package, you'd just have to create the HTTP message handler chain yourself manually for your long-lived static client.

We wouldn't add extensions that would only benefit a subset of HTTP methods and/or content types when there is already functionality available to inject Polly into the HTTP pipeline to handle any possible request.

[eduherminio]

If you don't want to use HttpClientFactory, then you could still use the delegating handler that wraps calls with Polly from the Microsoft.Extensions.Http.Polly package, you'd just have to create the HTTP message handler chain yourself manually for your long-lived static client.

Oh, thanks for pointing me out to that!
Being able to properly configure the HttpClient that way would make me totally agree with your position about the extensions I suggested.

Would something like this make sense to you regarding handler chaining, to combine the Policy one with the Sockets one needed to control the PooledConnectionLifetime?

   AsyncRetryPolicy<HttpResponseMessage> retryPolicy;

    var client = new HttpClient(
        new PolicyHttpMessageHandler(retryPolicy)
        {
            InnerHandler = new SocketsHttpHandler() { PooledConnectionLifetime = TimeSpan.FromMinutes(15) }
        })
    {
        BaseAddress = new("...")
    };

[martincostello]

That seems correct to me.

[eduherminio]

Cool, thanks for your support Martin!