Consuming a web API using a typed HttpClient — .NET Core

Cheranga Hatangala
May 19, 2019 · 4 min read
Image courtesy by


In these days, it’s almost impossible to implement a decent system without implementing or consuming a web API.

Building APIs has always been a first class citizen and it has been evolving ever since in any programming platform with any major platform update or how we deploy our software.

In Microsoft related technologies, we have evolved from implementing an ASMX web service to implementing and deploying an API using Azure functions (yes, WCF, MVC, Web API approaches are, still widely used).

In modern (well maybe not so modern) times consumption of a web service has never been easy with the introduction of response types such as JSON (application/json). In this post I am going to discuss about how to consume a REST based API where the responses are in JSON format. For that I’ll be using .NETs HttpClient .

Alright, so what’s the big deal?

Well, as developers we would like to write beautiful, functioning code. So when we saw HttpClient was implementing IDisposable interface, we used it within an using statements because that’s the sensible (A.K.A — best practice) thing to do. But… boy we were wrong! 😆

Well that’s one object which you shouldn’t be messing with by wrapping inside an using statement.

By default the behavior of an HttpClient instance is it’s thread safe and can be reused. So if you have many HttpClient instances created; each instance will have it’s own connection pool (which basically means, there will be many sockets opened in a given time). The problem is, though you dispose the HttpClient instance, the underlying sockets will not be released that soon. So if you get a burst or if your API needs to serve many requests at the same time, it will fail to do at a certain point in time because the sockets will be exhausted.

A detailed and a thorough explanation how this thing happens is described in this awesome article written by Simon Timms.

Also, in Microsoft’s own documentation this is explained and it advises to create the HttpClient instance once and, keep re-using it. You can read more about it in here

Well unfortunately things doesn’t settle there actually. Having a singleton HttpClient instance, it cannot handle DNS changes. So well, how can we consume an API consistently and reliably? comes .NET Core 2.1

Well starting from .NET Core 2.1 Microsoft saw this becoming a real problem and introduced HttpClientFactory . As per the name, it’s a factory which we can use to create HttpClient instances without worrying about disposables, DNS changes and all that drama.

And, to be honest they did it in style! 👍 👍 👍

You can use the HttpClient in many ways. In this article I am going to demonstrate my favorite way. That’s by using a “Typed Client” approach. Also known as the “Service Agent Pattern”.

I am using a demo REST API as the web API to consume in this solution. The complete source code can be found in GitHub

Create a class library

Let’s create a class library because in reality we’ll implement this logic in a separate class library. To test the functionality we’ll implement integration tests.

Install the golden nuggets!

Well not really 😄 but we are going to need the below mentioned nuget libraries.

  • Microsoft.Extensions.DependencyInjection

This is required because we are going to register the service class so that the application can use it as a dependency.

  • Newtonsoft.Json

Since the API deals with JSON, we need this to serialize/deserialize content when we send and retrieve from the API.

  • Microsoft.Extensions.Http

This contains the latest and the greatest implementations/enhancements done in .NET core in relate to HTTP and, also it includes an extension method for the IServiceCollection so that we can easily register our implementation as the HttpClient. Yes, you guessed it right, this is where the typed client registration happens.

Create the model class “Todo”

This class is pretty straight forward and simple, you can just create it by just looking at the returned JSON from the API.

Create the service abstraction

We’ll implement the service abstraction as an interface.

Implement the service abstraction

Alright, let’s implement it now.

As you can see above, I have hard-coded the URL. The better way in my opinion is to create a separate class to represent this and, inject it through constructor dependency injection. To make things more focused I will not be demonstrating that in here.

Register the dependencies

For this I would like to separate the dependency registrations to a separate class called Bootstrapper .

As you can see we are using AddHttpClient extension method from Microsoft.Extensions.Http and registering the TodoService associating it with ITodoService . Now the application can inject ITodoService anywhere as it see fit.

Implement integration tests

Add a test project to the solution and let’s write some integration tests. I am using XUnit as the test framework.

Remember to add a reference to the service project once you create the test project.


We have now successfully created a service, which actually uses an HttpClient to consume an API. But as earlier we don’t want to worry about all the challenges which we had to deal before.



.NET, .NET Core, C#, ASP.NET Core, Architecture and Design

Cheranga Hatangala

Written by



.NET, .NET Core, C#, ASP.NET Core, Architecture and Design

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade