2

I'm creating .NET wrapper for some REST type API. I'm using HttpClient for communication (sending/recieving Json). There are many async methods.

Verification is via cookie that I'm receiving and storing in cookiecontainer. Should I have separate httpclient for every function or one global httpClient? If one separate for each function, what is the best method to share cookiecontainer and custom headers that are attached to every request?

Hooch
  • 28,817
  • 29
  • 102
  • 161

2 Answers2

2

I suggest keep the number same as the API you're calling (this is how I coded mine), meaning if you're calling to Twitter API, just keep one instance of HttpClient for that, and if you're accessing Facebook API in the same time, keep another one for that.

Keep in mind that some metadata cannot be change after a HttpClient has been created (e.g. DefaultRequestHeaders), which make sense since a HttpClient is meant to be reuse to make multiple calls (e.g. easy for cookies or auth information sharing).

Andy
  • 5,287
  • 2
  • 41
  • 45
  • So you suggest using Singletone pattern for HttpClient? Have staic method that will always return me reference to HttpClient? So one client per whole API? I'm still not sure if this is the right option. Other people suggested having one httpClient per action and have factory of httpClients. I have to make research on what are downsides to having one per appliation. – Hooch Aug 25 '14 at 11:06
  • @Hooch, Singleton mean you only have one instance of HttpClient for entire app. If you're accessing various different APIs, keeping an instance of HttpClient for each of them are more convenient. I'd make it `per function` only if it's not being use frequently. If you use HttpClient to access your backend db, it make no sense to repeatedly create the same thing over and over again, however if you're just running a cron job, then just make it per function. – Andy Aug 26 '14 at 00:19
-4

Definitely per function, in a using statement. Custom headers can be stored in a static variable as long as they're only being read from. The cookie container would likely require locking when working with any instance members.

w.brian
  • 16,296
  • 14
  • 69
  • 118
  • So in every using block I need to create headers and attack cookie? Or should I create "factory" function that will crete new instances of WebClients and automaticly add cookies to cookie container and headers? What if I want to share all cookies between all HttpClients? – Hooch Aug 22 '14 at 13:06
  • A factory function that would automatically create the HttpClient with the default headers seems like it would be a nice way to do it. Regarding a shared cookie container, it may be tricky and I can't say for certain how it should be implemented. I did find this SO question, but it pretty much echos what I already said: http://stackoverflow.com/questions/9911744/is-it-safe-to-use-the-same-cookiecontainer-across-multiple-httpwebrequests – w.brian Aug 22 '14 at 13:41
  • 4
    I'm not so sure about this answer, read this http://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/ – MetaGuru Sep 20 '16 at 15:37
  • 1
    I've heard the same as ioSamurai, better to have one HttpClient per application, or 'per service per application'... see here more discussion here: http://stackoverflow.com/questions/22560971/what-is-the-overhead-of-creating-a-new-httpclient-per-call-in-a-webapi-client Plus the official docs say "HttpClient is intended to be instantiated once and re-used throughout the life of an application" https://learn.microsoft.com/en-us/aspnet/web-api/overview/advanced/calling-a-web-api-from-a-net-client – mejobloggs Feb 27 '17 at 08:35