Returning Errors in a WCF RESTful Web Service

While writing web services I’ve used several different methods for returning errors. A very common method is to return null or if the response is a string return the word error or a message stating there was an error. That works, but I’ve never really been a big fan.

Example:

public object GetSomething(string param)
{
try
{
var returnObject = new object() = some code here
return returnObject;
}
catch (Exception ex)
{
return null;
  or
return new object();
 or
 some variation;
}

}

This method doesn’t really seem to comply with best practices for being RESTful or for OOP. It gets you by, but it’s kind of smelly.

More recently, especially with RESTful WCF Web Services that are returning complex objects, I’ve added DataMembers to the DataContract that include an error Boolean and error message along with the object(s) I’m returning as a DataMember.

Example:

[DataContract(Name=”returnObject”)]
public class returnSomeObjects
{
[DataMember]
public IList <someObject> { get; set; }
[DataMember]
public bool Error { get; set; }
[DataMember]
public string Message { get; set; }
}

Then in the error handling above:

catch (Exception ex)
{
return new returnObjects() {Error = true, Message = “ex.Message”};
}

I like this method more because it always returns the same object and the calling process can make a decision based on error being true or false. Even if you don’t have complete control of the returning object(s); for instance when wrapping a legacy class library with a service, you can just make the object a DataMember on the DataContract and away you go.

The problem with this method is the http response is a 200 ok, even though an error occurred. So, it’s not as smelly, but still not the best practice. Recently I’ve begun to favor a more organic approach. Something that is more RESTful in nature, that is modifying the http status code to reflect that an error has occurred.

Example:
catch (Exception ex)
{
OutgoingWebResponseContext response = WebOperationContext.Current.OutgoingResponse;
response.StatusCode = System.Net.HttpStatusCode.InternalServerError;
response.StatusDescription = “A unexpected error occurred!”;
}

You could evaluate the exception and return codes based on certain situations, I use the above for unexpected errors. You could also make the response.StatusDescription the exception message. The calling process can now key off of the http status code and handle the situation as required by it’s own system and rules.

You might ask, why modify the status code? If you just simply throw the error you achieve something very similar, that is a HTTP status code other than 200 ok. The issue, for me at least, is you get a 400 bad request. Which is a little misleading to the caller and not exactly true if somewhere in my data or logic layer an error has occurred.

So I like to add a little control. You can evaluate for invalid parameters or data and still return the 400 bad request when appropriate, but for unexpected errors, I like returning the 500 Internal Server Error.

I should mention I’m using this for internal web services so I do have more latitude in what I show to the calling processes and systems, however, I see no reason why using standard http response codes would be a problem in a public API.

Additionally, this method adds more consistency to what a calling process will get when errors occur. For example, with the previous methods if your service is unreachable they would get a different response then if it is reached and a custom error is returned. In other words, they can always evaluate the response codes that are native to http giving you a more RESTful response.

Advertisements

About Shawn Sweeney

I'm a father, software developer, and runner. I blog about things related. View all posts by Shawn Sweeney

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: