Are these the main differences between RestSharp and ServiceStack's Client Code?

Question

I have been unable to make a definitive choice and was hoping that somebody (or a combination of a couple of people) could point out the differences between using RestSharp versus ServiceStack's client services (keeping in mind that I am already using ServiceStack for my service). Here is what I have so far (differences only). The list is fairly small as they are indeed very similar:

ServiceStack

Pros

• Fluent Validation from my already created service POCO objects
• One API for both client and service
• Code reads better (i.e. Get<>(), Post<>())

Cons

• Some of my strings must be written out (i.e. If I make a GET request with query parameters, I must create that string in my code)
• I must create a different class for each Request/Response Type (JsonServiceClient, XmlServiceClient)

RestSharp

Pros

• Just about everything can be a POCO (i.e. If I make a GET request with query parameters, I just add the parameters via code)
• Switching between Request/Response types is simple (request.RequestFormat = DataFormat.Json/Xml)

Cons

• Manual Validation (beyond that found in the Data Annotations)
• Two APIs to learn (this is minor since they are both fairly simple)
• Code is not as readable at a glance (barely) (i.e. request.Method = Get/Post.. and main call is Execute< T >())

I was leaning towards RestSharp since it tends more towards straight POCO use and very little string manipulation, however I think ServiceStack might be acceptable to gain the validation and code that is more easily read.

So, here are the questions:

• Which do you prefer?
• Why the one over the other?

I know this is not a totally subjective question, but at bare minimum I am looking for the answer to this question (which is subjective):

• Are any of my findings incorrect and/or are there any that I missed?

Solution

As the project lead of ServiceStack I can list some features of the ServiceStack Service clients:

The ServiceStack Service Clients are opinionated in consuming ServiceStack web services and its conventions. i.e. They have built-in support for structured validation and error handling as well as all clients implement the same interface so you can have the same unit test to be used as an integration test on each of the JSON, JSV, XML, SOAP and even Protobuf service clients - allowing you to easily change the endpoint/format your service uses without code-changes.

Basically if you're consuming ServiceStack web services I'd recommend using the ServiceStack clients which will allow you to re-use your DTOs you defined your web services with, giving you a typed API end-to-end.

If you're consuming a 3rd Party API I would recommend RestSharp which is a more general purpose REST client that is well suited for the task. Also as ServiceStack just returns clean DTOs over the wire it would also be easily consumable from RestSharp, which if you prefer its API is also a good option.

---

UPDATE - Using ServiceStack's HTTP Client Utils

ServiceStack now provides an alternative option for consuming 3rd Party APIs with its HTTP Client Util extension methods that provides DRY, readable API's around common HttpWebRequest access patterns, e.g:

List<GithubRepo> repos = "https://api.github.com/users/{0}/repos".Fmt(user)
    .GetJsonFromUrl()
    .FromJson<List<GithubRepo>>();

Url extensions

var url ="http://api.twitter.com/statuses/user_timeline.json?screen_name={0}"
    .Fmt(name);
if (sinceId != null)
    url = url.AddQueryParam("since_id", sinceId);
if (maxId != null)
    url = url.AddQueryParam("max_id", maxId);

var tweets = url.GetJsonFromUrl()
    .FromJson<List<Tweet>>();

Alternative Content-Type

var csv = "http://example.org/users.csv"
    .GetStringFromUrl(acceptContentType:"text/csv");

More examples available from the HTTP Utils wiki page.

Comments

[John Sheehan]

As the project lead of RestSharp, I fully endorse this answer.

[Justin Pihony]

Thanks! +1 and accepted.

[kay.one]

It's so nice to see you guys get along :D

[Rodney S. Foley]

I would like to add that I think the project lead of ServiceStack doesn't realize what he has. ServiceStack in making creating services easier and faster to do, and consuming their own services equally so it has also made consuming 3rd party REST API's super easy as well. Its simple Request DTO's serialization to a Query String and its simple and fast parsing of JSON to response DTO's has this a great API to use only as a client against Google and many other REST API's. Nothing against RestSharp but ServiceStack is even easier and cleaner to use as a client in my opinion.

[GFoley83]

@JohnSheehan As a prospective user of either RestSharp or ServiceStack's HTTP Client, it would be very useful to have a post from you on here similar to mythz's above. IMHO.

[John Sheehan]

Don't use RestSharp. Use something that's still being worked on.

[Henrik Karlsson]

Looks like Haaked is maintaining RestSharp at least temporarily haacked.com/archive/2013/09/18/restsharp-104-2-0-released.as‌​px

[Eternal21]

Looks like ServiceStacks is paid now for commercial projects: servicestack.net/pricing

[mythz]

@Eternal21 ServiceStack.Text which contains HTTP Utils as well all of ServiceStack's serializers and client libraries is free for everyone.