Here’s an example:

var client = new RestClient("http://example.com");
var request = new RestRequest("resource", Method.POST);

client.ExecuteAsync<Resource>(request, (response) => {
    var resource = response.Data;
});

As a side note, the core library is also now set to use the Client Profile by default. The Async methods from Silverlight/WP7 are also available in the core library as well.

I know it’s very cliché of .NET open source projects to be perpetually unreleased but I’ve sort of come to like not having a release. In the current state of the project, there’s a minimum level of involvement in order to use RestSharp. Having a slightly higher bar for using it tends to limit use to 1) people that know how to report bugs 2) people more willing to contribute back and 3) people less likely to need a lot of help. These three things really make it a low-maintenance project, which is nice because sometimes I’m pretty busy.

I previously wanted to release fast and furious with quick updates after 1.0. Now, I’m taking my time to get 1.0 rounded out better. I’ve reprioritized oAuth (in progress), Silverlight (mostly done) and Windows Phone 7 support (not started) for 1.0.

However, you may not have to wait too much longer because of some things I can’t yet discuss that are giving me some more time to work on RestSharp. Stay tuned.

On Documentation

If you’ve previously checked out RestSharp then written it off because you couldn’t figure it out and there were no docs, I’ve written a lot of documentation since then. If you have a chance, read through it and let me know what’s missing.

On "Competition"

There are some other .NET REST Clients that have either recently launched or are somewhere around the corner. The most interesting development is Microsoft’s re-entry into the problem space with their upcoming REST updates to WCF being spearheaded by Glenn Block (of MEF fame). I’m honored to hear that the WCF team has evaluated RestSharp and best I can tell doesn’t hate it. I would love for a proper REST client (or even HTTP client) to be included in the framework and eliminate the need for RestSharp. I’ll be keeping an eye out for what they develop and rest assured if it doesn’t meet my standards, RestSharp isn’t going anywhere. If it does, then I’ll re-evaluate things then. Either way, I’m glad to see increased interest in REST from MS and other developers. The more the merrier!

On Pure REST vs. Mainstream REST

RestSharp is very much situated in the "Mainstream REST" (aka Web API) category. Almost to the point where I wish I hadn’t included ‘REST’ in the name. When I started I had no idea what a rabbit hole pure REST is. I don’t mean that in a bad way, just it’s more complicated than my original understanding. I am attempting to keep an ear to the REST purists to gain inspiration for how things should work. However, my #1 goal is to get things done and since most of the APIs I work with also fall into the mainstream REST category, that will continue to be my focus for RestSharp.

On Community

When I started this little project I never imagined that anyone else would like it, let alone use it, let alone contribute to it or write blog posts about it. For all of those people listed in the Acknowledgements and blog posts list, thank you for your support of RestSharp. We’re over 100 watchers+forks on GitHub and almost 150 followers on Twitter. RestSharp was even featured on the GitHub blog. Your contributions have made it a better library and an even more fun project to work on! Thank you everyone!

While looking at the examples for a new .NET REST library that’s recently been released, one thing stuck out to me as a good idea to steal and implement in RestSharp. It has to do with what is returned from Execute methods.

Which do you prefer:

1. The Status Quo

RestClient client = new RestClient();
RestResponse response = client.Execute(request);
var statusCode = response.StatusCode;

Product product = client.Execute<Product>(request);
var name = product.Name;

2. Always return a RestResponse, sometimes with the entity

RestClient client = new RestClient();
RestResponse response = client.Execute(request);
var statusCode = response.StatusCode;

RestResponse<Product> responseWithData = client.Execute<Product>(request);
var code = responseWithData.StatusCode;
var name = responseWithData.Entity.Name;

I’m leaning towards #2 because it gives you access to the complete response details on every request.

Your thoughts?

RestRequest.ResponseFormat has been removed because it was too naive. If your requests return XML and specify an XML content type, the XML deserializer will be used and likewise for JSON. If you want to override those deserializers or need to handle a different content type, use the following methods:

var client = new RestClient();

// clear default handlers
client.ClearHandlers();

// add custom handler
// second parameter is instance of IDeserializer
client.AddHandler("application/json", new FunkyDeserializer());

By default the following content types are handled:

• application/xml
• application/json
• text/xml
• text/json (please don’t use this in your apps, supporting it because it’s out there)

By default if the content type returned by your request doesn’t match one of those content types the XML deserializer is used. To register a default handler use client.AddHandler("*", …); You can also remove specific handlers using client.RemoveHandler(contentType);

1.0 Release Update

I know I promised February 24 but a couple bugs and some good feedback items came in and I wanted to resolve them by 1.0. Now I’m going to be on vacation and at MIX so it will likely be shortly after that. Follow @RestSharp for updates.

One thing I want to make note of for anyone that’s already using RS is a breaking change that will be committed soon. The ‘BaseUrl’ property that currently resides on RestRequest will be moving to RestClient. RestClient is where you want to be handling configuration that is common amongst many requests (like authorization which is typically pretty standard across an API) and the base URL for an API rarely changes between requests. This change will be checked in tonight.

Once the remaining issues are taken care of and the docs are beefed up I’ll release RestSharp 1.0. My goal is to have done by February 24th but it will likely be sooner than that.