RestSharp 114 is a wrapper around HttpClient, and its front page still explains version 107

RestSharp sits on top of HttpClient, so HttpClient's behavior is the floor

The second line of the README settles the main question about this library: RestSharp is a lightweight HTTP API client library, a wrapper around HttpClient rather than a full-fledged client on its own. That framing decides where bugs live. Connection pooling, handler configuration and anything HttpClient decides by default reach you unchanged, and RestSharp's own value is the layer it puts on top: default parameters of any kind rather than only headers, parameters that can be query, URL segment, header, cookie or body, several ways to add a request body including JSON, XML, URL-encoded form data and multipart form data with and without files, built-in JSON, XML and CSV serialization with room for custom serializers, and authentication support described simply as rich.

RestClientOptions replaced client configuration so the client could be thread-safe

The compatibility note is the most useful paragraph on the front page, because it names what version 107 deprecated. Client configuration moved to RestClientOptions, which the project gives as the reason for making the client thread-safe. IRestClient had its interface surface substantially reduced, IRestRequest and IRestResponse were deprecated in favour of implementing classes, SimpleJson was deprecated in favour of System.Text.Json.JsonSerialzer, and everything named Http and IHttp was deprecated because those are just wrappers. The consequence for a reader is that code written against the pre-107 API needs migrating, and a reduced IRestClient means less surface to substitute in a test. The v107+ notes at https://restsharp.dev/v107 are where that migration is written down.

Serialization is chosen by package reference, so a CSV project carries an extra assembly

Four packages split the serialization choices out of the core. The core RestSharp package carries the System.Text.Json serializer and what the README calls a basical XML serializer. Newtonsoft.Json support, the custom RestSharp XML serializer, and CsvHelper each live in their own package, and the identifiers you reference are the whole configuration surface for this decision:

RestSharp
RestSharp.Serializers.NewtonsoftJson
RestSharp.Serializers.Xml
RestSharp.Serializers.CsvHelper

Read the last two rows as a choice rather than a bundle. A project that wants Newtonsoft.Json as its JSON serializer needs both the core package and RestSharp.Serializers.NewtonsoftJson, and a project that parses CSV exports ends up with CsvHelper in its dependency list even though it never makes a request with it. The XML story is split across two packages as well, with a basic serializer in the core and a custom one behind RestSharp.Serializers.Xml, so which XML behaviour you get depends on which assembly you referenced.

One maintainer, and the README's answer to a bug report is a pull request

The support section is unusually direct about what you can expect. RestSharp is described as an open-source project with a single maintainer, and the README says not to expect an issue to be resolved unless it concerns a large group of RestSharp users. It then names the alternative it prefers: fix the issue yourself, fork the repository and submit a pull request. Sponsoring the project is offered as a way to motivate the maintainer. For an engineering team this is the section that matters most, because it rules out planning around an issue queue. A defect that affects one integration is yours to patch, and the maintainer is a single person. The other channels are ordinary community ones: the docs site, Stack Overflow with the tag restsharp, and a Discord server.

The compatibility note explains 107, and the release line is at 114

Version numbers and documentation have drifted apart here. The latest release is 114.1.0, published on 2026-10-21, preceded by 114.0.0 on 2026-03-05 and 113.0.0 on 2025-11-28, and the last push to the dev branch was on 2026-10-21, with the repository not archived. The compatibility note on the front page explains RestSharp 107 and nothing after it. That leaves seven majors between the migration advice you can read on the front page and the version you would install today, and the README does not summarize what 108 through 114 changed. Anyone upgrading from a recent 11x version gets no front-page guidance for that jump either, so the diff you care about has to come from the release history rather than from the documentation you land on first.

RestSharp.snk and agents.md sit in the root next to RestSharp.slnx

The repository root shows how the project is built and who it answers to. It contains RestSharp.snk, the strong name key file, so the assembly identity is the project's choice rather than a per-consumer setting, and it contains Directory.Packages.props for central package version management, which is how one repository keeps several projects on the same dependency versions. The solution is RestSharp.slnx with a companion RestSharp.slnx.DotSettings, and the tree carries src/, test/, docs/, benchmarks/, props/ and gen/. Two instruction files at the root, CLAUDE.md and agents.md, mean the repository ships its own guidance for coding agents. The license is Apache 2.0 in LICENSE.txt, and the project is part of the .NET Foundation, which is the institution behind the code of conduct it enforces by blocking users who violate it.

Five additions to weigh against the layer they put over HttpClient

The decision this library asks you to make is narrow. What you gain is parameter handling that does not require string assembly, several body encodings including multipart with files, serialization for JSON, XML and CSV, custom serializer registration, and authentication helpers. What you take on is an abstraction between your code and the transport, which means two places to look when a request behaves unexpectedly, and a version history that broke its own interfaces at 107 and has not been summarized since. Teams that already own a typed HttpClient wrapper with a serializer chosen for their payloads are duplicating that wrapper by adopting RestSharp, while teams writing many small integrations by hand are the ones who get the most back. That is the whole trade, and it is worth deciding before you read further documentation.

Editorial conclusion

Adopt RestSharp when your .NET code makes many calls with varied parameter kinds and you would rather not hand-roll query strings, multipart bodies and serialization, since those five additions are the whole product and HttpClient does the transport underneath. Do not adopt it to escape HttpClient, because that is the library doing the work, and do not adopt it if your process needs a vendor-backed support answer, since the README names a single maintainer and says your issue will not be resolved unless it affects a large group of users. Before you pin a version, read the v107+ notes at https://restsharp.dev/v107 and diff them against whatever RestClient surface your code already calls, then decide which of the four serializer packages you actually need.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. restsharp/RestSharp on GitHub