This is also the ideal interface to implement an instance-per-key IoC strategy.Initializes the underlying implementation (like libcurl) with the given configuration data. So how do you get a single instance per web service? The answer lies with the IFlurlClientFactory interface, which exists primarily so that Flurl's instance-per-host default behavior can be overridden.
However, a singleton that depends on a transient is considered bad practice and some containers won't allow it. This is getting closer to what you want - a single instance per web service. Register IFlurlClient as a transient and your services as singletons. In something like an ASP.NET application where controllers are frequently created/disposed, that's tricky, and really should be the job of the container. The problem here is that the onus is now on the application to ensure the service class instances are long lived and re-used. Register IFlurlClient and the services that depend on it as transients. The drawback here is if your application interacts with more than one web service, you can't use stateful properties like BaseUrl or Headers or they'll likely collide. Here are some options for registering IFlurlClient with your container:
It provides interfaces for its core classes, most notably IFlurlClient. You can explicitly create a FlurlClient and (optionally) configure it fluently: var cli = new FlurlClient("")įluent calls off a FlurlClient start with the Request method, which optionally takes one or more URL path segments: await cli.Request("path", "to", "endpoint") // shortcut for Request().AppendPathSegments(.)įlurl.Http is well suited for use with IoC containers and dependency injection. Most of these properties and methods are used to set defaults that can be overridden at the request level. FlurlClient includes a BaseUrl property, as well as Headers, Settings, and many of the fluent methods you may already be familiar with. It implements IDisposable, and when disposed will also dispose HttpClient. Managing Instances Explicitly ☍įlurlClient is a lightweight wrapper around HttpClient and is tightly bound to its lifetime. So for example, if you are hitting both http and https endpoints of the same host, you'll have 2 client instances that can be configured independently.
* As of 3.0, scheme are port are also part of the cache key. Fluent methods like this will create an HttpClient lazily, cache it, and reuse it for every call to the same host*: var data = await "".GetJsonAsync() This will result in SocketException errors.įlurl.Http adheres to this guidance by default. Especially in server applications, creating a new HttpClient instance for every request will exhaust the number of sockets available under heavy loads. HttpClient is intended to be instantiated once and re-used throughout the life of an application. If you're familiar with HttpClient, you probably already know this advice: Flurl.Http is built on top of the stack.
0 kommentar(er)
