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
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
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
HttpClientinstance 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?
Behold..here 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”.
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.
This is required because we are going to register the service class so that the application can use it as a dependency.
Since the API deals with JSON, we need this to serialize/deserialize content when we send and retrieve from the API.
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
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.