Closed rynowak closed 7 years ago
Is your statement about the existing API not being that bad based upon an assumption that people don't really consume it anyway? Since I would've assumed that a new HTTPClientFactory would maintain the lists of delegating handlers and I would just give it a name. No?
bad based upon an assumption that people don't really consume it anyway?
Yes, these are static methods that are basically infrastructure.
Since I would've assumed that a new HTTPClientFactory would maintain the lists of delegating handlers
Yes, but this is an implementation concern not part of the API.
I expect that we'd add:
public abstract HttpClient CreateClient(string name);
// Maybe
public virtual HttpClient CreateClient();
We will use:
namespace System.Net.Http
{
public interface IHttpClientFactory
{
HttpClient CreateClient(string name);
}
}
This will ship in the Microsoft.Extensions.Http
package.
We are not concerned about confusion between HttpClientFactory
and IHttpClientFactory
.
We're comfortable making this an interface instead of a class because we think we're got the API nailed down and it's minimal.
@rynowak Quick question:
Will there be official documentation about this class AND how to use it in code?
I'm asking this about the lack of information (or discovery of this information) with respect to the current status quo with HttpClient
and how many people still enclose this in a using
statement ... until recent times (q3/q4 last year) when AspMonsters dropped that blog post which made a heap (nearly all?) of us go 'what the heck?! really?? /me face palms'.
Not trolling/hating - just want to make sure everyone gets onto the same page, as early as possible.
👍 🍰
Will there be official documentation about this class AND how to use it in code?
Yes, what we're doing in this repo is building a library and a pattern for using HttpClient
with DI in a configurable way. This is planned as part of the ASP.NET Core 2.1 release but will be usable outside of ASP.NET Core.
The .NET team is also looking at some of the foundational issues that have made using HttpClient
difficult.
thank you heaps @rynowak for the info! Sounds great :) Can't wait to see and use this :)
P.S. Please don't forget UNIT TESTING scenario's 👍 🍰
8a64334
At first I was like: 😞 😢 😭 😠
And then I was like: 😕 🤔 😃 👍
https://msdn.microsoft.com/en-us/library/system.net.http.httpclientfactory(v=vs.118).aspx
The fqn
System.Net.Http.HttpClientFactory
already exists in the old WebAPI client library. This is where we we also provide things likeReadAsAsync<T>
methods and the general support for formatters and deserialization. We own this library and control it's destiny 👍Basically we expect users to use this package and the name
HttpClientFactory
will conflict betweenMicrosoft.Extensions.Http.HttpClientFactory
and andSystem.Net.Http.HttpClientFactory
. This will be broken for a lot of people.:canada: Fortunately, we Canadians have the same word for crisis as we do for opportunity :canada:.
Please note that most of the types we need to interact with for
HttpClient
are inSystem.Net.Http
. We were going to addMicrosoft.Extensions.Http
as a companion namespace. We expected that users will have to sprinkle someMicrosoft.Extensions.Http
around their code - but this was a non-goal.Please also note that it is not a breaking change to change a type from static to abstract, in fact a static class is declared as
sealed abstract
at the IL level - and unsealing is not a breaking change.At this point a plan starts forming in my mind. Don't reply until you get to the end. I know some of you are going to type a response before you read all of the steps. Here's what I think this would look like:
System.Net.Http.XYZ
- pick whatever name you wantHttpClientFactory
into this new packageSystem.Net.Http.Formatting
now depends on this new packageSystem.Net.Http.HttpClientFactory
and add whatever we decide is required.Microsoft.Extensions.Http
as the implementation ofHttpClientFactory
including the wire-ups for DI, logging, and optionsPros
Microsoft.Extensions.Http
namespace isn't required unless you are implementing extensibilityHttpClientProvider
🤒) this is still going to be annoying for anyone usingSystem.Net.Http.Formatting
.Cons
HttpClientFactory
which is IMO not that badWhy another package This solves an issue with coupling.
Right now
HttpClientFactory
lives in theMicrosoft.AspNet.WebApi.Client
package, where it also has a whole bunch of infrastructure for formatters, content negotiation, and also a reference to JSON.NETWe anticipate that
Microsoft.Extensions.Http
to have a bunch of references to otherMicrosoft.Extensions.*
packages. We really don't want to introduce coupling either way. You don't want things like DI and options showing up in your old ASP.NET WebAPI 2 project, and you don't necessary want WebAPI2 formatters in your ASP.NET Core project.If we have to live with the coupling one way we'd probably want to reference
Microsoft.AspNet.WebApi.Client
fromMicrosoft.Extensions.Http
. Most of what's there is still pretty relevant, and it's not coupled to any server-side abstractions.