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

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?

Answer 1

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.