RequestBody constructor made obsolete

[ExtraClock]

In fd23c08 RequestBody constructor made obsolete: "The RestBody class will be internal in future versions".

We have API which uses XML request-response, so we use UseDotNetXmlSerializer.
However, in Authenticator we need to replace generated XML body with signed application/pkcs7-mime. So we take request.Body.Value, sign it and replace entire request.Body with new RequestBody("application/pkcs7-mime", "application/pkcs7-mime", signedBody)

With RequestBody constructor made obsolete what is the right way for authenticators to replace entire request.Body?

[alexeyzimarev]

Thanks for the feedback. The idea is to decrease the public API surface of RestSharp as now it gives too much freedom to access the library internals. As the result, a lot of people are using the library incorrectly and then open issues for things that are, in fact, self-inflicted wounds.

Your case seems absolutely legit and when removing some of the public APIs I am always open to alternatives.

I'd rather use a custom serialiser in your case, but you replace the request body in the Authenticator. May I ask why? Do you get to know something in the Authenticator that gives you the required parameters for encryption?

[ExtraClock]

May I ask why?

It seemed logical to place authentication code inside an authenticator :)

Do you get to know something in the Authenticator that gives you the required parameters for encryption?

I have access to the encryption keys all the way from instantiation of RestClient to the moment I make a request, so it's not a problem.
It seemed convenient not to think how do serializers work and to place authentication code inside authenticator. However, I had to create custom deserializer anyway (I need to check response's signature and to convert it to an object), so maybe you are right and it would be better to put all sign/verify logic in custom serializer/deserializer.

[ManniAT]

I have a similar problem reported here #1555
Althoug I understand your intention you should at least provide a way to set the body content "directly" - just like it can be done using the constructor.
I use a rest API which requires "plain text" (no quotation mark or something like this) and without using the constructor I found no way to call the API without an error.

[TimSirmovics]

I also have the same issue, I require a body with content type multipart/mixed.

[keithbarrow]

Hi when this is done can the RequestBody implement a IRequestBody or something. I'm passing the request into a method as part of a fall-back mechanism - being able to set the body value is very useful for testing things like malformed and well formed requests etc. At least with an interface we can pass a mock into the function.

[mj2015]

Just to add my 2c, I too now have an API that I have to pass a string "as-is" to as the body. I appear to have no way in RestSharp, so it looks like my years using RestSharp as my goto are over. Sorry, but you must support people passing in their own body content, even if it is an "AddPlainBodyAllMyResponsibility()" function. Thanks for considering it.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[repo-ranger]

⚠️ This issue has been marked wontfix and will be closed in 3 days

[TimSirmovics]

Any plans to revert this?

[alexeyzimarev]

@TimSirmovics if you submit a PR removing the Obsolete attribute, I will merge it.

[TimSirmovics]

@alexeyzimarev I forked the project , but it doesn't build due to Package FluentAssertions 6.2.0 is not compatible with net452

Seems like dependabot is updating packages even if it causes the build to fail? #1641

If I downgrade the package I feel that dependabot will update it again.
How do you want to handle this?

[alexeyzimarev]

@TimSirmovics I know, it's unfortunate. The upgrade was suggested by dependabot. If you plan to submit a PR, feel free to downgrade incompatible packages.

I plan to remove support for .NET Framework versions that are out of support by Microsoft, but I can only do it in the next major version.

Dependabot only opens PRs, it's up to me to merge them or not. I won't merge the FA upgrade PR when it comes again, until the times come.