Use HttpClient instead of FSharp.Data.Http

[baronfel]

Let's talk about this here instead of cluttering the 1.0 PR.

Info on how to use HttpClient correctly:

• Doing it wrong: https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/
• Doing it right: https://www.stevejgordon.co.uk/introduction-to-httpclientfactory-aspnetcore

Can we lift some of the implementation details from the httpclient factory or something?

[sergey-tihon]

What if it will be the responsibility of SwaggerProvider user?
Or at least this behavior is not the part of the provided code, only some simple default behavior in default ctor.

We generate the client that inherits from SwaggerApiClientBase, but the user can inherit from our provided client and override any behavior.

type SwaggerApiClientBase() =
    abstract member CreateClient: unit -> HttpClient
    abstract member Serialize: obj -> string
    abstract member Deserialize: string * Type -> obj
    abstract member CallAsync: HttpRequestMessage -> Task<HttpResponseMessage> 

• CreateClient - aka factory method, default implementation may return singleton instance created by default ctor.
• Serialize/Deserialize - allow injecting the code in serialization process, but it tricky... would be nice to support more than just json with JSON.NET, but it is not clear how to handle renamed properties (current implementation adds json.net specific attribute)
• CallAsync is the replacement for CustomizeHttpRequest, this method allows users to modify requests, add auth header or cookie, log calls, measure performance, implement caching and mock api calls

[sergey-tihon]

Or even better, we do not need CreateClient, the only place where we need it is CallAsync. So in order to change the behavior user have to override CallAsync.

So one provided client (lets sayPetStoreClient) has one HttpClient inside.
If the user uses short living PetStoreClient objects - everything is fine. If user needs long-living client or wants to use the single instance for application is should override the default and simple CallAsync behavior.

I think that it may be hard to guess the behavior that covers all use cases and keep it simple at the same time (from the early beginning), so we can start from something simple as default.

[baronfel]

So the intent would be to generate clients using this new base class (or allow the user to specify a base type that we could dynamically construct), then instead of RuntimeHelpers.XXX use this.XXX via expressions/reflection?

[sergey-tihon]

Correct, my initial idea was to generate client based on SwaggerApiClientBase with some default behavior implemented but allow users to create a new client that inherit from the generated client and override behavior.

Also, replace RuntimeHelpers.XXX to this.XXX, we have this as 1st parameter of instance methods and we can find XXX once outside of quotation like you do with cast, so this.XXX should not be an issue.

What do you think about this approach?

Update: I think that we need the method like CallAsync for Fable support, that may be decorated with an attribute that provides alternative JS implementation of request execution.

[baronfel]

I think you're right about needing CallAsync. If we're worried about Fable, though, we can't necessarily use HttpRequestMessage and HttpResponseMessage either, right? Those don't exist for Fable?

Edit: It would be very hard to make a ClientBase<'Request, 'Response> and have us be able to do anything reasonable with 'Request in the emitted methods, I think. We could perhaps have specializations for dotnet and fable respectively and have a static parameter differentiate between the two?

ie. create two base classes, one exposing types for .Net, another exposing types for Fable, then have parallel execution paths in the type provider's emitted code that emits one or the other.

[sergey-tihon]

We can ignore Fable for now, it is another (and quite hard) topic and focuses on stabilizing API and extension points.

[sergey-tihon]

I think that our goal should best support for .net (in terms of API and performance)
Both HttpRequestMessage and HttpResponseMessage is OK to use.

Also after listening plans for .Net Core 2.1 I think that HttpClientFactory is good way to go as well ( just need to check that it exist for net45 and play nice on full framework)

[sergey-tihon]

Implemented in #117