Install

Install-Package RestSharp

(or download)

Documentation

Get Started - All

Contributions welcome!

Discuss

RestSharp Google Group

Help and feature requests

Stay Updated

Follow @RestSharp

Subscribe to the RSS feed

New Deserialization Feature: Different Root on Error

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?

Posted November 3rd, 12:59 AM
Read more posts about Announcements.

7 Comments - Join The Discussion
Link

  • http://blog.prabir.me/ Prabir

    its good feature to have inbuilt support for catching Exceptions for Client.Execute.but i think the one you proposed might not be such a good idea.it works very good if u follow the pattern where u return response follows some patterns. like or {message:’Error occurred’,success:true} or what ever. but for old restful services this doesnt work out at all. let me give u an example from my facebook implementation example. facebook doesnt return consistent message if there is an error. sometimes it just returns “false” (which is not even a valid json), or “{error:’error message’}” (i would blame fb for their api’s but we have to deal with these). and they dont’ use propert http status code at all, most are usually 200OK. heres the code how i check if the request was error. pretty long. https://github.com/prabirshrestha/FacebookSharp/blob/v0.1.1.0/src/FacebookSharp.Core/Exceptions/_FacebookException.cs#L46because of different error handling i never used the generic version of Executerather i implemented different generic mechanism, https://github.com/prabirshrestha/FacebookSharp/blob/v0.1.1.0/src/FacebookSharp.Core/RestSharp.cssince the comment is getting to long i think i better i create a google groups discussion.

  • Einar

    I also like the idea of being able to define the error response but I don’t like that it is mandatory. In the most recent code (commit 123569ff982fe5e4fed7) get a null ref exception if I don’t (using the Silverlight client). There should be some default implementation of this function which checks for the usual error codes such as 4XX and 5XX.

  • http://dkdevelopment.net dkarzon

    Thanks John, exactly what I was after. I’ll give it a go and let you know how it goes.

  • http://john-sheehan.com/blog John Sheehan

    Thanks Einar, I’ll get that fixed today!

  • http://lucisferre.net Chris Nicola

    If we are truly deserializing resources then chances are we get a completely different resource when an error occurs than when a success occurs. If I succeed I probably want to deserialize to a Client object, but if it’s an error then I’m going to expect an RestError object.

  • http://john-sheehan.com/blog John Sheehan

    This was eventually implemented as OnBeforeDeserialization on
    RestClient that gives you access to change things after the request is
    made but before deserialization.

  • Frode Rosand

    Execute(request) is a far better solution here. Typically you receive totally different objects back and an Execute method with an option separate TError type would simplify everything.