-1

The MS docs say "HttpClient is intended to be instantiated once and re-used throughout the life of an application" - this seems fair enough but not so simple when you are using HttpClient from within a web app. All the examples out there using HttpClient are done with console apps and infact i cant find any examples with a web app consuming an API using HttpClient. So my question is whether HttpClient is actually meant to be used from a web app or should i be using WebRequest or something else? Thanks to anyone who replies!

Addition 24hrs later....its a .net framework app. Sorry i only just catching up with the answers, i have never used this site before and assumed i would get an email when answers posted - sincere thanks for all your comments and looks like i have some reading to do

Improve this question
4
  • The example given for that very guideline in the MS Doc is an example of web app code. That code stores the HttpClient in a static readonly field in an ApiController. Commented Apr 26, 2020 at 15:05
  • You can use it from web app, if you are working with an IOC library you can set this as a singleton and only 1 instnce will be created and injected when you need it. Commented Apr 26, 2020 at 15:05
  • .NET Framework or .NET Core? this links shows you how to use HttpClient in an ASP.NET Core application learn.microsoft.com/en-us/aspnet/core/fundamentals/… Commented Apr 26, 2020 at 15:20
  • fair point JLRiche but its just for one controller, so presumably each controller has its own static instance?? which, for me, still doesnt quite meet the MS line of "instantiated once and re-used throughout the life of an application" Commented Apr 27, 2020 at 10:22

3 Answers 3

Reset to default
1

Thw preferred way is to use HttpClientFactory

You can then simply inject HttpClient in your Services and let the DI container worry about the lifetimes.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

0

If you are using dotnet core then use HttpClientFactory if not use a private static field for your HttpClient. These are the recommended best practices. The second option still poses some issues but they are more edge cases and won't end up exhausting your sockets. This article explain s things very nicely https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/

Improve this answer

4 Comments

I would recommend using the build-in IoC container and injecting the HttpClient rather than creating a static field for unit testing and extensibility reasons.
As I said with dotnet core that would be the approach but the original question doesn't suggest that the user is using. Net framework or dotnet core.
sorry Andrew for not clarifying i was using normal .net framework web app - that article was what i first stumbled across that got me wondering about all this, and it too uses a simple console app. Sounds like i can have a static class with a static instance of HttpClient which i can use from anywhere in my website - that just feels weird/unsafe to me as for each request i will be changing the bearer token - guess i just need to try it!
alaying my fears on previous comment..........stackoverflow.com/questions/37928543/…
0

Console apps are often used for tutorial projects because they are easier to create and run without the added complexities involving service hosting. It is easier to use a console project to illustrate the functionalities of HttpClient than from inside a web application. Also, it is worth mentioning that all .NET Core apps are console applications.

In the production environment, web apps are hosted on web servers, containers, windows services or in server-less environment so managing the life cycle of the HttpClient is important and following Microsoft's recommendation makes sense here. You will most definitely be using an IoC container for managing the object graph in your applications. You can configure the IoC so the life cycle of the HttpClient is either a singleton or instantiated per HTTP request.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.