according to several resources (link 1, link 2) there should be a single HttpClient instance per application instance, shared across all the threads, reused for every http call.
While this seems to be possible to achieve with bare HttpClient, I don't really know what is the correct usage when it comes to JsonHttpClient. According to this response, and looking through the code, it looks like there is a single instance of HttpClient per JsonHttpClient, which is disposed when JsonHttpClient is disposed.
Does this imply there should be a single, re-used instance of JsonHttpClient too?
How to deal with "per-context" properties like UserName / Password / BearerToken etc in such case?
Technically, I think it is possible to manage single instance of HttpClient manually, then assign it to newly created JsonHttpClient. But that would require us to un-tie HttpClient instance before disposing JsonHttpClient, othwerwise it'd get disposed too.
This looks like an extremely fragile and error-prone solution.
JsonHttpClient encapsulates a single instance of
HttpClient, you would use it the same you would the
HttpClient instance, i.e. share the same instance.
If you need different context properties just create separate instances. Having a few instances isn't anywhere near the same as creating a new instance per request which is a common usage and pitfall for
HttpClient. If the API designers wanted to mandate that you should only have 1 instance they would've made it a singleton (or have a singleton instance available) and not made it disposable.
You can inject the
HttpClient instance in different
JsonHttpClient instances if you really want to, but you should measure to determine it yields actual benefits before pre-maturely adopting the added code maintenance overhead.