RestClientOptions and its properties should have setters

[konarx]

It is related to changes that happened within the #1963 scope

Use case:
It is a common practice that the Authentication token is not provided during the initialization of the RestClient and has to be fetched later from a specific URI (eg. "/auth").

This was working in v108:

        _restClient = new RestClient("https://my-base-uri");

        var request = new RestRequest("auth")
            .AddJsonBody(new UserCredentials("user", "password123"));

        var response = await tempClient.PostAsync<LoginResponse>(request);
       
        _restClient.Authenticator = new JwtAuthenticator(response.Token);

This is a workaround in v109:

        //Creating a temporary RestClient only to perform a POST call to get the token
        var tempClient = new RestClient("https://my-base-uri");

        var request = new RestRequest("auth")
            .AddJsonBody(new UserCredentials("user", "password123"));
        
        var response = await tempClient.PostAsync<LoginResponse>(request);
           
        //In v109, the 'RestSharp.ReadOnlyRestClientOptions.Authenticator' has no setter.
        //For this case, a new instance of RestClient must be created
        _restClient = new RestClient(new RestClientOptions
           {
               BaseUrl = new Uri("https://my-base-uri"),
               Authenticator = new JwtAuthenticator(response.Token)
           });

Outcomes:
Instanciating 2 RestClient just to change one (or more) properties in Options is not optimal. My humble opinion is to create an instance of RestClient and to be able to change just the specific properties you may require.

[alexeyzimarev]

I disagree that the options object exposed via the Options property must have setters. I closed around 10 issues when people were assigned options after clearing the client using those setters, and expecting the client to work differently. It defeats the purpose of options and goes against the options pattern where options are used to configure the service when it's instantiated. That's why none of the .NET components that uses options allows to change the options after the component is instantiated. That's also why they never expose the options object. However, RestSharp users want to inspect the options, so I made it public. It's also useful when options properties are used in extensions, that's why it's also exposed via the interface. It was quite a lot of work to achieve that, but it works now.

In short:

• Most of the options are used to configure the HTTP client and the message handler. Changing those options won't have any effect, and it was confusing, people reported this behaviour as bugs.
• Making the options mutable makes the client not thread-safe without wrapping each setter in a lock.
• Changing the client behaviour at runtime causes unpredictability

What you want is to support the authentication flow and reuse the client to make the authentication call before making other calls. However, it's a completely different issue compared to making the options mutable.

[konarx]

Thank you @alexeyzimarev ,

I agree with your statement, so the feature request remains. The RestClient should not be instanciated twice to make the authentication call. If you agree, I will proceed and rephrase the topic & the description of this issue.

[alexeyzimarev]

Isn't it a duplicate of #2024

[repo-ranger]

Duplicate issue created! Closing in 15 seconds...

[alexeyzimarev]

Sorry about that, the repo ranger is too aggressive

[alexeyzimarev]

Ok, it is certainly a duplicate of #2024, I renamed that issue to make it clear that it concerns the particular issue with reassigning the authenticator. The title of this issue is a bit confusing as I described the reason for making options immutable. Please add any further comments to #2024.