I’ve added support for Silverlight 4 and Windows Phone 7 to RestSharp. Please try it out and report back any errors or other feedback you have. You can download the latest revision here.
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.
On Releases
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!
I was recently a guest on the Herding Code podcast to talk about RestSharp. The episode also covers my new job at Twilio, the .NET OSS landscape and me mentioning Bing two too many times. You can listen to the episode here.
I’ve posted another RestSharp-based library on GitHub called FoSharp for accessing the Notifo API. This is a really useful and simple API that currently lets you send notifications to an iPhone (other devices are in the works). The API is small and straightforward and with RestSharp I wrote a wrapper in under 30 minutes. Expect to see more of these types of projects pop up on my GitHub page.
UPDATE: The change described below has been committed to the GitHub repository.
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?
Breaking Change
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.
Progress on RestSharp has been steady lately with the addition of handling for file downloads, gzip/deflate compression handling, JSON request bodies and more. We’re down to just two outstanding issues and then I’ll be ready to christen and release RestSharp 1.0. If you have any features or bugs you want to get included in the first official release, now is the time to report them.
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.
I’ve submitted a session for the MIX10 open call on using REST APIs in your .NET applications. This talk will make extensive use of RestSharp. Even if you’re not going to MIX, you can still vote for the talk. It only takes 20 seconds and you don’t have to provide any personal information. You can vote here.
I just posted over on my personal blog how RestSharp came to be.
The first public commit of RestSharp went up on GitHub just a few minutes ago. I’m hoping to crank out some basic docs and do a downloadable release over the next few days. Stay tuned!
