37

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?
Justin Pihony
  • 62,016
  • 17
  • 131
  • 162
  • 1
    sadly i think this question will get closed because it's too subjective. i haven't used servicestack, so i can't compare them, but i can answer or clarify any restsharp questions. – John Sheehan Apr 12 '12 at 05:33
  • first clarification, `new RestRequest("resource", Method.POST);` what's not readable about that? :) other than it's probably backwards – John Sheehan Apr 12 '12 at 05:34
  • 1
    by two APIs to learn you mean servicestack on the server side and restsharp on the consuming side? – John Sheehan Apr 12 '12 at 05:35
  • what would you rather have Execute() be called? i never really liked that name but couldn't think of anything better. – John Sheehan Apr 12 '12 at 05:37
  • 2
    i pinged Demis to come represent his side :) – John Sheehan Apr 12 '12 at 05:37
  • 1
    my guess is that if you're using servicestack on the server-side, you're probably better off using it on the consumption end too. restsharp is really meant for arbitrary 3rd-party HTTP/REST APIs – John Sheehan Apr 12 '12 at 05:38
  • 3
    @John Sheehan: You should totally chip in on this yourself :) – BoltClock Apr 12 '12 at 07:25
  • @JohnSheehan As I said, the readability is very minor and really only noticeable when compared to ServiceStack's implementation (being able to call client.Get("resource") reads more fluently than having two lines where one sets up the method and the other is a generic call). I actually found it readable until I compared it, and do think that is the best naming unless you change the structure from the request object saying the method to the Client saying the method. Even ServiceStack just calls the same method under the covers (for the most part), so it is just the public facing part – Justin Pihony Apr 12 '12 at 14:58
  • @JohnSheehan Also, you are correct about the two APIs – Justin Pihony Apr 12 '12 at 14:59
  • @JustinPihony Your 1st con under ServiceStack "Some of my strings must be written out..." isn't really true. You can create a POCO for the Request and the client (ie JsonServiceClient) will build the Query string for you. As for you second con under ServiceStack is more of why would you try to support XML and JSON, just pick one and stick with it. Its your service and your client you can lock it down to just one. If you offer a public REST API you can add XML but you don't have to support it in your own client. – Rodney S. Foley Dec 26 '12 at 05:09
  • If using .Net 4.5+, consider to use HttpClient - see http://www.diogonunes.com/blog/webclient-vs-httpclient-vs-httpwebrequest/ and http://stackoverflow.com/questions/21805541/how-can-i-convert-this-net-restsharp-code-to-microsoft-net-http-httpclient-code – Michael Freidgeim Jan 24 '16 at 21:28

1 Answers1

54

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.

mythz
  • 134,801
  • 25
  • 234
  • 373
  • 71
    As the project lead of RestSharp, I fully endorse this answer. – John Sheehan Apr 12 '12 at 05:58
  • Thanks! +1 and accepted. – Justin Pihony Apr 12 '12 at 15:00
  • 15
    It's so nice to see you guys get along :D – kay.one Apr 20 '12 at 01:37
  • 2
    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. – Rodney S. Foley Dec 26 '12 at 01:03
  • @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. – GFoley83 Jul 10 '13 at 22:27
  • 9
    Don't use RestSharp. Use something that's still being worked on. – John Sheehan Jul 19 '13 at 06:17
  • Looks like Haaked is maintaining RestSharp at least temporarily http://haacked.com/archive/2013/09/18/restsharp-104-2-0-released.aspx – Henrik Karlsson Sep 19 '13 at 12:59
  • Looks like ServiceStacks is paid now for commercial projects: https://servicestack.net/pricing – Eternal21 Apr 03 '18 at 20:27
  • @Eternal21 [ServiceStack.Text](https://github.com/ServiceStack/ServiceStack.Text) which contains HTTP Utils as well all of ServiceStack's serializers and client libraries is free for everyone. – mythz Apr 03 '18 at 20:33