I have to start this post by thanking Andrew Young for coming on as a core contributor and doing most of the work that made this release possible. Everything unattributed below was done by Andrew and he managed all the pull requests. Thanks Andrew!
Version 102 is on NuGet and GitHub Downloads.
Changelog:
- NEW: Added Windows Phone 7.1 Mango assembly. No differences from Windows Phone 7.0 assembly but should hopefully avoid some NuGet versioning conflicts if JSON.NET adds a Mango version.
- NEW: Mono for Android support added (thanks gshackles!)
- NEW: Added support for DateTimeOffset values in JsonDeserializer (thanks tathamoddie!)
- NEW: Added RestRequestAsyncHandle to allow for canceling async requests
- NEW: Added support for ClientCertificates to RestClient
- NEW: Added DotNetSerializer (thanks liddellj!)
- UPDATED: MonoTouch version synced with main version
- UPDATED: RestResponse.Content is now lazy-loaded on first access to avoid performance hit of populating both RestResponse.RawBytes and RestResponse.Content
- FIXED: Set compression settings for async requests
- FIXED: Better date/time handling in JsonDeserializer (thanks tathamoddie!)
- FIXED: Better handling of multipart form data (moved paramter data before file data) (thanks willkelleher!)
- FIXED: Deserialization of a list of primitives when XML elements are namespaced (thanks ArturDorochowicz!)
- FIXED: Made line endings for request bodies conform to standards across platforms (thanks thrackle!)
- FIXED: Fixed bug with writing double-byte unicode
- FIXED: Incorrect content length when unicode characters present
- FIXED: Inconsistencies in culture handling
Report any issues to the Google Group. Enjoy!
Minor fixes and enhancements.
NuGet and GitHub downloads updated.
Just a couple small bug fixes in this one:
- FIXED: JSON.NET reference issues should finally be resolved. The JSON.NET package changed their assembly to be strong named in between when I added the reference in my project and when the last release was made.
- FIXED: OAuth parameters now sort correctly in more cases (thanks cdeutsch!)
- FIXED: JSON.NET fixed some bugs in 4.x around JSON string handling that broke a few deserialization cases.
NuGet and GitHub downloads updated.
Get it on NuGet or GitHub downloads. Also, if you have a moment, I would appreciate your rating and review of the project on the NuGet gallery.
- Updated JSON.NET to 4.0.2
- IMPROVED: Windows Phone 7 now supported via NuGet (thanks to NuGet 1.2 and JSON.NET updates)
- IMPROVED: References to JSON.NET and xUnit now done via NuGet (should resolve issue where there was an error with JSON.NET when installing RestSharp via NuGet)
- FIXED: Async requests weren’t setting Accept header based on registered deserializers
-
FIXED: MonoTouch project was out of date (thanks
kevinmcmahon!)
-
FIXED: Async requests that set Timeout value threw exception
-
FIXED: Content length is sometimes incorrect when using unicode characters in request body
-
FIXED: Timeout value only set in async requests when it does not equal 0
If you use RestSharp in a project that I can link to and show off, please email me with the name of the project and where I can point people to. I want to build up a better showcase of how people are using the project to better promote RestSharp and your projects.
RestSharp 101.0 is now available on NuGet (Update-Package RestSharp or Install-Package RestSharp if not yet installed) and GitHub downloads.
Changes:
- NEW: You can now specify an IHttp implementation to be used via RestClient.HttpFactory [0]
- NEW: Deserialize JSON directly to Dictionary<string, string> (thanks lucisferre!)
- IMPROVED: File uploads now support parameter name (thanks thecutter!)
- IMPROVED: Standardize on InvariantCulture in XmlDeserializer. Overridable via XmlDeserializer.Culture property. [1]
- IMPROVED: Execute methods now virtual
- IMPROVED: Set ServicePointManager.Expect100Continue = false
- IMPROVED: Set HttpWebRequest.UseDefaultCredentials = false
- IMPROVED: Better URI encoding (thanks lucisferre!)
- IMPROVED: Updated to JSON.NET v4
- IMPROVED: Better element name matching when deserializing directly to List<T>
- IMPROVED: Better deserialization of generic objects with generic lists.(thanks ayoung!)
- FIXED: Async requests now acknowledge timeout value (thanks ayoung!)
- FIXED: JSON body get truncated when it contains unicode characters that encode to more than one byte. (thanks SneakyMax!)
- FIXED: Some oAuth1 Access Token requests failed (thanks codemonkeylabs!)
- FIXED: oAuth1Authenticator didn’t work when a POST parameter was present
- FIXED: URL Encode when replacing templated URL segment values (thanks ayoung!)
[0] Injecting your own IHttp implementation
var client = new RestClient();
client.HttpFactory = new SimpleFactory<FakeHttp>();
[1] Setting the Culture on XmlDeserializer
var client = new RestClient();
client.AddHandler("text/xml", new XmlDeserializer { Culture = CultureInfo.CurrentCulture });
Both of these APIs will probably be overhauled and cleaned up in RestSharp 2xx.
Thanks again to the fantastic community of contributors! I could not keep this project going without you guys. Also thanks to Jon Fuller for his behind-the-scenes contributions in this release window.
This happened over a month ago, but the first official release of RestSharp is now available. As previously discussed, the first version is 100. And also as expected, there were numerous bugs discovered after the first release and so there have been subsequent releases with the current being 100.3. 100.4 is just around the corner as a bunch of community contributions have just landed in the repository as well.
The easiest way to install and keep up to date is with NuGet. Just run Install-Package RestSharp from the NuGet console or search for it in the Add Library Package Reference dialog. If you prefer your binaries in zip form, you can download from GitHub. Note that the assemblies in the downloadable zip file have been ILMerged where possible (Framework and Silverlight) to avoid conflicts if you’re already using JSON.NET in your project.
Going forward I’ll try to post a changelog here on the blog for each release.
If you need help, the recently-created Google Group has been an excellent resource for getting problems solved, so I’d recommend starting there. While you’re free to email me still, I’ll likely refer you to the list first since there are more people available to help at any given time.
Once development on RestSharp 100 stalls, I’ll likely move it to a “maintenance mode” whereby I’ll curate any pull requests, but won’t be actively adding new features to it. I’ll then create a second project for RestSharp 200 where the majority of development will happen. This will let me make more drastic changes without forcing everyone to adapt. RestSharp 200 will also drop support for .NET 3.5. I don’t know when RestSharp 100 will run out of steam but something to keep in mind for the future.
A lot of features have landed lately. I feel so fortunate to have such a great community of developers contributing to the project. Don’t believe everything you hear about the .NET open source community!
Here’s an overview of what’s new:
oAuth 1 Support
Daniel Crenna ported Hammock‘s oAuth implementation into a nice oAuth1Authenticator for RestSharp. I’ll be updating the documentation soon, but for now you can check out some sample usage examples in this test. Props to Daniel for this much needed addition.
AddFile support for async requests and better file upload handling
Andrew Young and Jon Fuller have totally overhauled the handling of file uploads including adding support for multipart forms in async requests. Since I did not want to tackle this myself, I’m VERY appreciative of their efforts.
Added RestClient.FollowRedirects and RestClient.MaxRedirects
At the request of Brandon Kaid I added access to the underlying HttpWebRequest.AllowAutoRedirect and HttpWebRequest.MaximumAutomaticRedirections properties via two properties on RestClient: FollowRedirects and MaxRedirects.
MonoTouch Support Added
Kevin McMahon worked out the kinks and got MonoTouch added. Thanks Kevin!
These are all great features on the march to the first release, which is (for real) just around the corner. It will be called RestSharp 100 Continue. Whenever the next release is, it will be called RestSharp 200 OK. Not sure how sustainable that is, but I’m going with it for now.
In the process of implementing the changes described in this earlier post, I came upon what I think is a much more useful design that could be the start to more changes like this in the future. Instead of ErrorCondition and ErrorRootElement, which are too narrow to be useful outside of specific scenarios, I’ve changed it to work like the following instead:
var client = new RestClient(BaseUrl);
var request = new RestRequest("BadUrl");
request.RootElement = "Success";
request.OnBeforeDeserialization = resp =>
{
if(resp.StatusCode == HttpStatusCode.BadRequest)
{
request.RootElement = "Error";
}
};
var restResponse = client.Execute<RestResponse>(request);
// Write(restResponse.Message);
This gives you complete control to react to any response payload and adjust deserialization and other settings accordingly.
Release Update
While we’re here, an update on where things are at. The emergence of NuGet has pushed me to change my mind on releases and I’d like to get a 1.0 out. oAuth has been the big blocker here, but thanks to an idea from Daniel Crenna I think I’ve got a workable approach to get that in without having to try to shoehorn everything into an oAuthAuthenticator. That’s the last major hurdle to a first release. Once I’ve got the oAuthHelper implemented and a couple more issues from the issue tracker taken care of, there will be an official ‘RestSharp Release 1′.
If you have any feature requests or bugs, now is the time to get them in the system. If you’re not sure if it’s a bug or not, start with the Google Group.
Some APIs out there return different schemas when an error is encountered. Using the default deserializers and their direct mappings to a single schema it can be difficult to handle these situations. Because error conditions vary so widely, we needed a way to let you specify them for each request. I’ve checked in a change tonight to accomplish this. This only exists in the desktop framework sync methods right now, but I wanted to show it off and get feedback.
Here’s what it looks like:
var client = new RestClient(BaseUrl);
var request = new RestRequest("BadUrl");
request.RootElement = "Success";
request.ErrorRootElement = "Error";
request.ErrorCondition = resp =>
{
return resp.StatusCode == HttpStatusCode.BadRequest;
};
var restResponse = client.Execute<RestResponse>(request);
// Write(restResponse.Message);
-- RestResponse.cs --
public class RestResponse
{
public string Message { get; set; }
}
If ErrorCondition returns true, the deserialization will start from a root element named Error. If everything works and there are no errors, deserialization will start from Success. You’ll still have to pack everything into a single class. I may add another overload to like Execute<TSuccess, TError>(request).
What do you think?
