[RFC] v109

[alexeyzimarev]

RFC for v109.

New features

Done, awaiting feedback

• IRestClient interface with Options, Serializers, ExecuteAsync, and DownloadStreamAsync
• Target frameworks: .NET 6, .NET 9, .NET Framework 4.7.1, .NET Standard 2.0
• Using the Configuration pattern for options, serializers, etc

Planned

• RestClientFactory implementation. It is unclear if we should use IHttpClientFactory or an internal factory like it's done by Flurl. Using both might work too.

Breaking changes

• Serializers configuration using a delegate passed to the constructor. UseXXX methods to configure serializers moved to the SerializerConfig
• Authenticator, Encode, EncodeQuery moved to RestClientOptions
• Options exposed by the client changed the type to IRestClientOptions where most of the properties are get-only. Also, properties that configure HttpClient or HttpMessageHandler are not included to IRestClientOptions.

Motivation

The client instance should not be as mutable as it is today. The current API allows making configuration changes at runtime, which can produce undesired side-effects when the client instance is used in multi-threaded scenarios.

Example serializer configuration

Before:

var client = new RestClient(url);
client.UseNewtonsoftJson();

After:

var client = new RestClient(url, configureSerializers: cfg => cfg.UseNewtonsoftJson());

[nesc58]

Sounds good. I have tested the prelease and it works good for me.
We have used the method BuildUri(request) for logging purpose because the uri contains the whole uri including query parameters. This changed to be internally now. Is it possible to keep the method public on the RestClient implementation or provided as extension method? I don't need the BuildUri method on the IRestClient interface. The interface should be clean and minimalistic and this method is not relevant for an implementation contract.

Thank you for your great work

[alexeyzimarev]

The BuildUrl method can't be an extension as it accesses the private properties of the client. If it is made public, it should be part of the interface. I also don't like it being there, need to think about it.

[nesc58]

The only property not including in the interface is DefaultParameters.
If this will not be a part of the interface or of the IRestClientOptions it could be optional:

public static Uri BuildUri(this IRestClient restClient, RestRequest request, ParametersCollection? defaultParameters = null) {
    defaultParameters   ??= new ParametersCollection();
    var (uri, resource) =   restClient.Options.BaseUrl.GetUrlSegmentParamsValues(request.Resource, restClient.Options.Encode, request.Parameters, defaultParameters);
    var mergedUri = uri.MergeBaseUrlAndResource(resource);

    var finalUri = mergedUri.ApplyQueryStringParamsValuesToUri(
        request.Method,
        restClient.Options.Encoding,
        restClient.Options.EncodeQuery,
        request.Parameters,
        defaultParameters
    );
    return finalUri;
}

If this method will not be accessable in future it is bad for me but solveable.

Another part I want to discuss is the IDisposable on IRestClient. I know it it really common to use IDispoable on interface level because it makes a lot of things easier. But the main purpose to inherit IDispoable is to release (unmanaged) resources. An interface self not contains any resources. But I can understand the descicion to use it on interface level ot make a lot of things easier.

The last point: Is it necessary that I can inherit RestClient? Currently there are no members to override. I think it could be public sealed class RestClient : IRestClient when no virtual members exists.

I am really looking forward to the next release 👍 The changes are great and I hope the people who hates the v108 will be happy to see the interface again and the new cleaned up configuration pattern

[alexeyzimarev]

I am not saying it won't be there. The code you pasted shows how many private functions it uses, not just properties.

I am not sure how people use it. For example, HttpClient doesn't expose how they build the URL internally, although it is quite primitive compared with RestSharp.

I have nothing against bringing it to the interface. The only issue is that for any composition-based implementation (think Polly-based retry client), the implementation of BuildUrl will be to call the wrapped client.

Considering the diagnostics need, there's an issue to add an ActivitySource and start activities when making requests. The activity payload can contain the URL, and adding a simple listener to the activity source would solve the logging needs.

That's why I am interested in using particular public functions, as they might be used for the needs of alternative solutions.

[Bidthedog]

Any chance of adding support for request-based cookies as per #1792?

[alexeyzimarev]

Any chance of adding support for request-based cookies as per #1792?

It's already there in v109 preview

[Bidthedog]

Oh, OK, sorry! I'll see if I can check it out today - thanks @alexeyzimarev :)

[rbobrowicz]

Hello,

I'm not sure if I should comment here or open a separate issue, but we noticed an issue with cookies in the v109 preview.

Essentially, the problem we have is that we use RestSharp to talk to a third party API that we don't control and that API sends us invalid cookies. They look something like this: Set-Cookie: [redacted]; Expires=Thu, 21 Dec 2023 01:16:59 GMT; Path=/; Domain=; Secure; HttpOnly; SameSite=None. The Domain=; bit is invalid as far as I understand the relevant cookie RFC.

Now, this used to work in v108, but in v109 it throws an error because the SetCookies() method of CookieContainer throws the following exception if you give it that header:

{System.Net.CookieException: An error occurred when parsing the Cookie header for Uri '[redacted]'.
 ---> System.Net.CookieException: The 'Domain'='' part of the cookie is invalid.
   at System.Net.Cookie.VerifySetDefaults(CookieVariant variant, Uri uri, Boolean isLocalDomain, String localDomain, Boolean setDefault, Boolean shouldThrow)
   at System.Net.CookieContainer.CookieCutter(Uri uri, String headerName, String setCookieHeader, Boolean isThrow)
   --- End of inner exception stack trace ---
   at System.Net.CookieContainer.CookieCutter(Uri uri, String headerName, String setCookieHeader, Boolean isThrow)
   at System.Net.CookieContainer.SetCookies(Uri uri, String cookieHeader)
   at RestSharp.RestClient.ExecuteRequestAsync(RestRequest request, CancellationToken cancellationToken)} 

Which leaves us between a rock and a hard place. We can't actually get the third party to fix their cookie headers, and it appears there is currently no way to disable response cookie parsing in v109 of RestSharp.

We don't actually care about the cookies at all, just the request body, so would it be possible to have a flag of some sort to disable cookie parsing so that an invaild cookie doesn't kill the request?

[alexeyzimarev]

I think it can be fixed. Will check before the new year.

[Bidthedog]

Do you have an expected / planned ETA for v109?

[alexeyzimarev]

I want to include the client factory in the new major, but I haven't figured it out yet.

[Bidthedog]

Is there anything I can help with, or is it one of those things you just need to hammer away at until it looks right? ;)

[alexeyzimarev]

Here's the discussion.

#1791

The easiest would be to do the same as Flurl does (use base URL as the cached instances key), but they neither do any lifecycle management nor handle cases when the HttpClient is (should be) configured differently even if the base URL is the same. I would prefer using IHttpClientFactory from Microsoft, but it won't cover those massive number of cases when people instantiate the new client instance for each request. There, the Flurl approach with some improvements like lifecycle management would be better.