Stay Foolish
Stay Foolish

Reputation: 3746

returning meaningful exception to the client in RESTFul API

I am in the process of developing some comprehensive RESTFul APIs using .net web api.

Basically there is an existing web application running already. We are developing an mobile app for that. Since there are existing implementation, I am trying to reuse the existing business layer code as mush as possible so that it is easier to maintain in the future.

However, I am having some issue regarding how to return the exception to the client. In the API layer, I call some business function to perform an operation. The business layer performs the operation and throw exceptions in some situation.

e.g.

public void ResultModel Process(InputModel input) {
  if (input is not valid) {
    throw new ApplicationException("some message");
  }
  // keep on processing
}

In the API layer, I am trying capture all the exceptions and then map to some pre-defined api exception

e.g.

http response code: 404
reason: the country information is incorrect 

http response code: 404
reason: invalid student id is provided

I was thinking in the API layer, i will create some error status code apart from the standard http status code.

eg.

http response code: 404
error code: error0001
reason: the country code is incorrect 

http response code: 404
error code: error0002
reason: invalid student id is provided

And then document meaning of the error code in the API documentation.

However, by doing that, i need to create a mapping between the business layer exception and the api response. The business layer implementation shouldn't be aware of this kind of exception. But I might need to change all the place an exception is throw to return some exception with some exception code and the map that exception code into the api error code.

This is what I can think of about solving the problem, but the code base that I am dealing is quite big, the effort of re factoring and implementing this solution is very big.

I am wondering if there is any better deign and easier way of addressing the issue? Or any ideas about this will be helpful for me.

Upvotes: 1

Views: 1376

Answers (2)

Jacques Snyman
Jacques Snyman

Reputation: 4300

To make it automated, you could generate a hash of the exception message and then combine it with @MariusSchultz's answer to generate a unique error code per type and message.

For example:

throw new ApplicationException("the country code is incorrect");

could be converted to error code 1-c955f43ad10c78d1baeca4f1e8a36d52, assuming the value of ApplicationException in the dictionary is 1 and you use an MD5 hash.

Similarly...

throw new SomeCustomException("some message");

could be converted to error code 2-df49b60423903e095b80d9b4a92eb065, again, assuming the value of SomeCustomException in the dictionary is 2 and you use an MD5 hash.

This is the best way I can think of to keep the WebAPI and the business layer decoupled and still automate the error-code process.

Upvotes: 0

Marius Schulz
Marius Schulz

Reputation: 16440

You could look up your custom error code within the exception filter attribute through a Dictionary<Type, int>, which maps (exception) types to their corresponding error code. If the lookup fails when no mapping entry is found, you could return a generic error code.

This way, your existing business layer doesn't need to know about API error codes. Also, every exception gets an error code as specific as possible and the generic error as a fallback.

Upvotes: 2

Related Questions