The RIGHT Way To Use HttpClient In .NET
HTML-код
- Опубликовано: 28 июн 2024
- Get the source code for this video for FREE → the-dotnet-weekly.ck.page/htt...
☄️ Master the Modular Monolith Architecture: bit.ly/3SXlzSt
📌 Accelerate your Clean Architecture skills: bit.ly/3PupkOJ
🚀 Support me on Patreon to access the source code: / milanjovanovic
The easy way to make HTTP requests in .NET is to use the HttpClient to send those requests. And it's a great abstraction to work with, especially with the methods supporting JSON payloads and responses. Unfortunately, it's easy to misuse the HttpClient. Port exhaustion and DNS behavior are some of the most common problems. So in this video, I'll show what you need to know about working with HttpClient correctly.
The Right Way To Use HttpClient In .NET
www.milanjovanovic.tech/blog/...
Join my weekly .NET newsletter:
www.milanjovanovic.tech
Read my Blog here:
www.milanjovanovic.tech/blog
Subscribe for more:
/ @milanjovanovictech
Chapters
0:00 The naive way to use HttpClient
1:10 Why is this a problem?
2:05 Using the IHttpClientFactory
3:34 Adding configurability with named clients
5:54 Strong typing with typed clients
9:17 Why you should avoid typed clients in Singleton services 
Наука
Get the source code for this video for FREE → the-dotnet-weekly.ck.page/httpclient
Hi Milan, I have a correlation Id in my web api. I used typed http client in mvc core 6 application. So in that case how to pass x-correlation Id in all my web API from client. Kindly suggest me..
I've been using named clients, but like the idea of strongly typed clients so may try them out. One advantage of being able to apply configuration once is that you can add Polly retry policies and they will be used for all instances of the named/typed client.
Where is your post?
Strongly typed and singletons have problems, so watch out.
@@zfold4702 ?
Named clients are awesome
Great content as always Milan...thank you🤴🏻
You're welcome!
Last part was very nice Milan. Many thanks. I preferred named clients many times in projects. I didn't prefer typed clients because I was a little afraid to delve into this lifetime issues when my services are singleton. I am just basically calling CreateClient method in my infra layer with a using() block. This approach didn't give me any problem so far in production.
I think you shouldn't manually dispose the instance. I am pretty sure the framework does that automatically.
I agree, if it works don't fix it. Right?
@@MilanJovanovicTech Yesss 😁
It was a nicely built overview. Thank you!
Glad you liked it!
Must awaited video. Thanks.
Hope you enjoyed it!
Thank you for the effort in this video!
You're welcome :)
Great !! keep the good work !
Thanks, will do!
Thanks for the infiniteTimeSpan. Cool tip 👍
Don't mention it 😁
Very good content! Thanks Milan.
You're very welcome!
Nice, have been working with typed clients for a while and find it to be a good approach. The only thing I do differently is inject configuration into the typed client and assign any required headers with the constructor, keeping the configure services nice and clean.
I think it's better to do the common things inside of AddHttpClient
@@MilanJovanovicTech fair enough, any particular reason?
I do exactly the same because i didnt figure out how to retrieve configuration with Option Pattern. I get null from the IConfiguration inside the HttpClient Configuration method. If someone have any idea
Hi, great video! I've just subscribed and I want to ask about the difference between the EShop and Gatherly projects, which one is better to learn from?
They're slightly different, cant' say one is better than the other
That's exactly what i was looking for, thanks Milan. Just one question, where do you think those typed clients belong to - Application layer or whatever?
Infra
HttpClient could lead you to place it in Infrastructure
You could create an interface in Application, however
Great Video Milan! Do you have a video showing how you would unit test this pls? (unit test IHttpClientFactory).
I don't yet, sadly. But I would take a look at MockHttp: github.com/richardszalay/mockhttp
Great explantion! Will you make a tutorial about Refit? Thanks!
Perhaps, I like that library. Maybe to compare it with HttpClient
Nice content as always! Could you make a video on how to use Swagger documentation with minimal api?
What's to be covered there?
Great video....can you please tell how I can configure multiple http client having different token mechanism and adding different authorisation header in each separate request.
You can use a delegating handler for each client
What about using Transient HttpClient service inside Scoped Services? Its ok?
No scoped services were used here
You can inject a httpclientfactory instead of httpclient in a typed client to get around the singleton issue.
What's the point of using a typed client then?
Thanks! Very well explained and clear code examples! I use the RestSharp for know - because it has support for oAuth1(I need it for an old smartHome device). Are there any helpers for oAuth1 and HttpClient?
I am not sure, to be completely honest
Great video! Thank you! Just to confirm when using named clients, the concern over transient vs singleton lifestyles isn't a concern? It's just with typed clients?
Correct. Since you use a factory to create the named client inside the method each time you invoke it, the lifetime of the class instance is not a factor at all. This is true only if the named client is created inside the method.
However, should you create (and capture) named clients inside the constructors, you will effectively introduce the same issues as when using the typed client. Capture the factory instead.
Yes, since with named clients you create an instance and dispose of it. If you capture the client in a field, you have a similar issue
O think you need to make another video explaining how to add retry using Polly. I recomend to use Backoff.DecorrelatedJitterBackoffV2 in this case.
Will do, great suggestion
Hi @Milan. This was an absolute great video and I am learning a ton from this channel and so, thank you. Hey, how can I use the above method (the 3rd way you describe in the above video) if I am working off of a class library project and I need to use httpClient within it. Basically, all my API calls are in a class library project. Is there an optimal way of using httpClient in it because I am worried about port exhaustion? Thanks
If you can create one HttpClient, pass it a SocketsHttpHandler instance at creation with some connection lifetime, and store it in a static field so that it's long-lived - that should suffice
@@MilanJovanovicTech , got it! It is that oldish pattern of using the HttpClient I guess. Thanks a lot!
Is the last solution for types clients with the lifetime settings a valid and good approach to use? or is it more on the hacky side? I have never stumpled upon it, and I knew almost everything else in the video. Though it was much more well explained than I have read.
MSFT recommendation: learn.microsoft.com/en-us/dotnet/fundamentals/networking/http/httpclient-guidelines
great video but I am wondering how you can configure with token that expires?
DelegatingHandler
Awesome explanation , but I have a doubt how can I Mock the http call using the typed approach?
I mean, I want to write a test for GetByUserNameAsync method where the internal httpClient simulates returning 200 and a predefined json
Check this out: github.com/skwasjer/MockHttp
You should show the strongly typed version using an interface instead.
You don't need interfaces for everything 🤷♂️
Hello Milan,
Thank you for amazing content. Something is bothering me regarding the configurations you need for a HttpClient. Let's say that you have some configuration stored in Azure Key Vault/Azure SQL Database, and each incoming request to our API has some kind of x-clientId header, how would you handle creating named HttpClient or strong typing HttpClient after retrieving some metadata on Azure Key Vault/Azure SQL?
Thank you, keep up the good work :)
I would explore an option of using a DelegatingHandler, to access Key Vault or SQL and get the configuration value.
How do you do when you need to fetch the access token dynamically and refresh when it expires with this approach?
Check this out: ruclips.net/video/_u6v4D6qgDI/видео.html
You need a DelegatingHandler on top of the HttpClient
you said using httpclient in traditional way can exhaust ports in long run, but is this true if we are doing proper dispose by applying using statements?
Yes - you'd end up creating too many handler instances. You want it to be long-lived
May I know how to add dynamic certificate using HttpClientFactory ? I have to use different certs.
learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/methods-auto/httpclient/httpclient-addcertificate-method
What i don't understand i why does it hate to make a new instance of the class injecting the httpclient if we could have a singleton do avoid being garbage collected all the time, is there issues with such techniques?
A new instance of which class?
Thanks
You're welcome!
What is good configuration for PooledConnectionLifeTime for Integration test project,
that have a hundred test with API calls?
How long does it take for your test suite execute?
What if you make the typed client a static class with a static HttpClient?
That works cool, since clients should be long-lived (at least the underlying message handler)
well done
Thanks!
why can not find video about creating read models eventualy with eventual consistency?
It's a recent video, look for Materialized views
My use case is a DLL which will be used with a winforms program. I expect that my DLL will be called periodically (hourly) and occasionally for a short burst of http activity. What video do you have that might help me choose the best implementation method? /Rob
"short burst of http activity" - it doesn't look like you can do much harm whichever implementation you opt for. You could create a static HttpClient in the DLL and reuse it.
ok but what if the token expires and you need to renew it / pass-in it again? to me it seems that with Factory approach you configure it statically at application startup phase.
Use a delegating handler
It is need to add "using" for httpClient, received from IhttpClientFactory?
No need, it'll be garbage collected
Typed clients has too many gotcha's. In addition to the messy stuff you added at the end, what if you have multiple services that require the same HttpClient configuration? I just used named configurations and only inject the factory, simples.
You'd configure the services separately
@@MilanJovanovicTech Indeed but then what you would have is all that malarkey to provide a specific configuration of a HttpClient which is only ever used by a single type and that type's only job is to wrap a specific configuration of HttpClient.
In that case again you might as well have that service type do all that work. It would take the factory and what other config services it needed, and have a private method that returns a configured HttpClient
If I were to call API2 from my API1 and the API2 accepts the bearer token that API1 call has is there a way to pass that as header using this method?
You can either create a request object, and set the header. Or set the DefaultRequestHeaders on the HttpClient
If I'm using 10 different named clients, then 10 object of HttpClient is created using IHttpClientFactory. How can we configure a single instance of HttpClient throughout whole application?
Well if you want to 10 _DIFFERENT_ named clients, you have no other choice
What if I just call AddHttpClient() and inject HttpClient into services contstructors? Do they share the same instance or every service gets its own copy?
I wanted to ask the same question! @MilanJovanovicTech I would really appreciate if you could elaborate on differences between factory injection and direct client injection 🙏
In theory, it shouldn't work - because no HttpClient would be wired up for that service
why not the "using" or "dispose"?
Not needed
It's a pity that AddHttpClient forces you to use service locator pattern
You win some, you lose some
Now extend this for clients that need to send Jwt Token in headers with refresh token capability
Will do, that requires Delegating Handlers
Admit that you saw my post a few minutes ago, and in 20 minutes you recorded a 12-minute video, edited and uploaded it. Just admit it, I'll forgive you..
Where is your post?
Yes!
If it was true, nothing wrong with this.
You forgot to dispose the clients.
You would only need to do it in the first example