@Henry Zhang Thanks for reaching out. Could you please use the concept of named or keyed registrations in Dependency Injection (DI) setup. In Startup class, configure the named registrations for different endpoints. For each endpoint, add a named HttpClient and a corresponding transient service.
public class Startup : FunctionsStartup
{
public override void Configure(IFunctionsHostBuilder builder)
{
var appSettings = /* retrieve or inject your AppSettings here */;
builder.Services.AddHttpClient("endpointA", client =>
{
client.BaseAddress = new Uri(appSettings.ApiEndpointA);
}).AddHttpMessageHandler<BearerTokenHandler>();
builder.Services.AddTransient<IProxyService, ProxyServices>("endpointA");
// ... Add more registrations for other endpoints
}
}
- In function class, use the Inject attribute to specify which named registration of IProxyService you want for that function.
public class AddToWaitlist
{
private readonly IProxyService _proxyService;
public AddToWaitlist([Inject("endpointA")] IProxyService proxyService)
{
_proxyService = proxyService;
}
[Function("AddToWaitlist")]
public async Task<HttpResponseData> Run([HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = "viewings/waitlist")] HttpRequestData req)
{
// Use _proxyService here
// ...
}
}
By using the [Inject]
attribute with the specified key (“endpointA” in this example), you’re telling the Azure Functions runtime to resolve the IProxyService
using the named registration you configured in the Startup
class.
This way, you can have different versions of ProxyServices
for different functions, each pointing to a different endpoint.
Please try and let me know if this helps!