Response Status Code handling

[itanex]

I am looking for a way to handle response status codes in a simplistic
way. I have a service that I really only care about 3 different
response status codes(200, 403, and 404).

I cannot locate a collection of exceptions that are designed to be
thrown in the restsharp github repository. These are the idea that i
was hoping to find:

throw new RestForbiddenException(...);
throw new RestNotFoundException(...);
throw new RestSuccessException(...);

Ideally it would be great to be able to subscribe to events that are
called by the response object so that I can designate certain methods
for certain responses. This is what I am thinking would be great.

responseObj.OnForbidden += HandleForbidden;
responseObj.OnNotFound += HandleNotFound;
responseObj.OnSuccess += HandleSuccess;

I have already mocked a few ideas up, to submit to the repository, but
I was wondering how other people handled the httpstatuscode in their
code in regards to restsharp before I go beyond mocking.

[John Sheehan]

Response codes are valid HTTP and not exceptional, so I catch those
exceptions. You can get the response code like this:

var client = new RestClient();
var request = new RestRequest();
// set options on those

var response = client.Execute(request);
var code = response.StatusCode;

[itanex]

Correct and that is how I am currently doing it. However, it would
make sense to be able to have it throw exceptions to allow catching of
them with a try/catch to handle proper RESTful controller actions in
MVC.

Currently I have to do the following to have my code react to
statuscodes:

var client = new RestClient();
var request = new RestRequest();

var response = client.Execute(request);

// Handle expected status codes properly
switch (response.StatusCode)
{
case HttpStatusCode.OK:
// reaction to HttpStatusCode
case HttpStatusCode.NotFound:
// reaction to HttpStatusCode
case HttpStatusCode.Forbidden:
// reaction to HttpStatusCode
default:
// reaction to HttpStatusCode
}

The other idea would be to subscribe events based on the statuscode at
the end of the request and handle each of those events as seen fit.
this would allow for better SRM objects and handling of RESTful
service calls. This would result in this API pattern:

var client = new RestClient();
var request = new RestRequest();

// Assign events on request to be handled appropriately
request.OnForbidden += MyForbiddenHandler;
request.OnNotFound += MyNotFoundHandler;
request.OnSuccess += MySuccessHandler;

// on this execution request/response would evaluate all the events
registered above that were needed
var response = client.Execute(request);

[John Sheehan]

You'll have to write a wrapper and use RestClient under the covers if you want to do that. There will be never exceptions thrown because of status codes in RestSharp. That's logic for your application, not the HTTP library.

[itanex]

Maybe I am not understanding what the restsharp library is providing
me that I cannot do directly on the webrequest/webresponse objects
in .NET.

Other then a simple call interface with an encapsulated object, how is
this a client if the client cannot react to the responses? Or be
taught to react to the responses?

[John Sheehan]

Easier deserialization, working auth, simpler API, easier async, and a
lot more. I don't want to defend its value. If you don't see the
value, go use HttpWebRequest. That class makes me want to light myself
on fire because of all the problems with it. That's why RestSharp
exists.

Status codes shouldn't raise exceptions. RestSharp gives you all the
data, it's up to you to act on it. Should there be an event handler
for every status code? There's quite a few. How do you pick and choose
which to include? I'm not going to pick favorites, everyone's needs
are different.

It's not the RestClient's job to execute your application logic. It's
just a transport mechanism.

[itanex]

Not saying that the response statuscode should be exceptional. I am
saying that just as you have deserialization, auth, simple API, async
support, and more, that there should be a way to make the client noisy
about its state. Otherwise you end up with a wrapper to your client
that connects in these events, that throw exceptions or events, just
to connect to an application.

[John Sheehan]

If you want to mock it up, feel free to send a pull request. You'll
have to make a pretty strong case though. I'm not seeing the benefit
right now.