Would it be right to use a static class to consume a web service?

Question

A question that occasionally arises when I am programming is related to the use of static classes.

To official documentation Microsoft says the following regarding static classes:

A Static class can be used as a convenient container for sets of methods that just Operate on input Parameters and do not have to get or set any Internal instance Fields.

So, it says that static classes can be used as a container for methods that only operate on input parameters and do not need to work with instance fields.

Let’s go to a more specific problem. My ASP.NET application consumes a web service that will return me information related to the business. To consume the web service I must do the authentication along with it, and after that send HTTP requests, simple, for that then I created a class, which I will call here ApiClient.

At no point in the process do I need to access class instance resources ApiClient, taking into account that data such as endpoint URL, access key and access key validity period will be the same for all who consume the class methods ApiClient.

So far I imagine that the user choice of a static class is correct. My question is the following, in case of multiple simultaneous calls of a class method ApiClient, if a request takes, say, 5 seconds, these requests would be queued, causing the static class to become a bottleneck in web service consumption?

Below is an example of the class ApiClient that I tried to describe.

public static class ApiClient
{
    private static string baseUri = "http://baseuri.com";

    private static async Task<string> GetKey()
    {
        //Get the key
    }

    private static async Task<string> SendRequest(string resource)
    {
        string key = await GetKey();

        HttpClient client = new HttpClient();
        client.DefaultRequestHeaders.Add("key", key);

        string url = $"{baseUri}{resource}";
        HttpRequestMessage request = new HttpRequestMessage(HttpMethod.Get, url);
        HttpResponseMessage response = await client.SendAsync(request);

        string result = await response.Content.ReadAsStringAsync();
        return result;
    }

    public static async Task<CustomerInfo> GetCustomerInfo(string customerId)
    {
        string resource = $"/api/method/{customerId}";
        string json = await SendRequest(resource);
        CustomerInfo customerInfo = JsonConvert.DeserializeObject<CustomerInfo>(json);
        return customerInfo;
    }       
}

Could this approach be considered problematic? In this case I would have bottleneck problem if multiple requests are passed to the method SendRequest? If yes this problem could be solved with the change of approach and creation of class instances ApiClient?

Answer 1

First, in fact I consider a correct approach. If it meets your needs I have no way of saying. Anyone who advocates OOP already says that they cannot do this, anyone who is pragmatic at first sees no problems. Who thinks that no code can be written if there are no tests will say that there is no test, who is pragmatic knows that only imposes a different technique, if formal tests are actually being done.

There is no difference of execution of static or instance methods. The only difference between them is that the instance method takes an extra hidden parameter called this. There is no different method for each instance, there is only one for the entire application, so its simultaneous execution is equal to the static method. The instance has been individual, but the behavior always belongs to the class, even if it gives the impression of being different.

You may have problems with the SendRequest() if it contains competition problem, which we can not evaluate with what was put, it is not that it could create bottleneck, it is that it could access two resources at the same time that can not be accessed at the same time, then it would require a coordination. But this is hypothetical, nothing indicates that this is the case.

I would only become baseUri readonly and eliminate unnecessary variables.