.Net web application with different api clients

Question

I have a Blazor project & i need to consume several REST APIs. All of those APIs require different configuration. For example: For one of those apis i have to bypass certificate by using ServicePointManager.ServerCertificateValidationCallback. And for another api i have to send GET request with bodypayload (which is not semantic). For another api i need JWT... and so forth. The point is that i have different HttpClinet(s) and they require different configuration.

So the question is how do you deal with it? You have all these amazing things in .NET like dependency injection, singleton, transient, IHttpClientFactory and you can configure your api client in startup.cs or in ctor or in any other place for that matter. So what is the right approach here?

I have a strong filling that something like strategy design pattern can be useful in this case

Answer 1

This is not a full answer but you can't add code to a comment

Are you talking about configuring different EndPoints on the Server, or how to configure different HttpClient requests in Blazor to those endpoints?

I can't cover all the options you have above, but here's an example. The code comes from the WeatherForecastDataServerice in a demo project of mine that adds a JWT token into the header of a API Call to a WeatherForecast API Controller.

public async ValueTask<List<WeatherForecast>> GetForecastAsync()
{
    _httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("bearer", myJwtToken);
    var response = await _httpClient.GetAsync($"/api/weatherforecast/GetForecastAsync");
    return response.IsSuccessStatusCode
        ? await response.Content.ReadFromJsonAsync<List<WeatherForecast>>()
        :new List<WeatherForecast>();
}

Answer 2

Everyone's least favorite answer- it depends.

How do you ultimately want to interact with the APIs? Do you want an interface per API that you interact with in a standardized way? Or do you want one large interface? If the former, consider using the adapter pattern. If the latter, the facade pattern, possibly layered over top of the adapter pattern. Either way, it sounds like each API you're working with is different enough that you'll want a relatively high level of abstraction in order to standardize how you interact with them.

In terms of what things look like under the hood, there's plenty of ways you could handle it. Strategy, delegate, command, builder, simple composition and/or inheritance, more that I'm not thinking of. It really depends on your goals, how different the APIs are from one another, how many more you intend to add, etc. There are so many ways to accomplish the same goal and much of how you approach this depends on your specific context.