CODEWITHSUNDEEP
jsonrestweb-servicescxf
Vanchinathan Chandrasekaran
Vanchinathan Chandrasekaran

Reputation: 5834

How to handle REST Exceptions?

We are in the middle of a ongoing discussion about how to handle REST exceptions.

Response Content type : JSON

Two solutions we have:

  1. Throw all the unchecked exceptions as a JSON response.
  2. Send Request Invalid Response code.

Arguments:

Counter Argument:

Whats your say??

Upvotes: 10

Views: 9636

Answers (3)

theking2
theking2

Reputation: 2838

For the developers consuming your REST it is helpful to provide as much information as needed but not more than that. You don't want to disclose too much information on your infrastructure do you? So you might want to distinguish between:

  • Bad parameters: 400 Bad Request
  • Resource not available: 404 Not Found
  • Not authorized: 401/403: Unauthorized
  • Internal: 500 Internal Server Error
  • Empty: 200 OK
  • Empty: 204 No Content

If an endpoint does not exist this would be a 404, if some internal system, e.g. a database is down or database logon fails a 500 and if the URI is not found a 404, 200 or a 204 (the debate is ongoing) but I prefer a 200 with an empty result for a URI representing a list of resources being empty but a 404 when a specific resource was required and not located. In all these cases you might provide a different body message helpful to the developer on the consumer end.

So you might want to distinguish exactly what exception occurred: an upstream error reporting is useless to the consumer, e.g. database errors, or an interface error which is very relevant to the consumer, like a query string containing unknown attributes.

Upvotes: 0

neal aise
neal aise

Reputation: 895

Use error codes like for HTTP. So 50* for any exception cause by some internal problem. And 40* for bad arguments. Avoid using your own defined codes as far as its possible. The idea is to have a "uniform" interface.

In general. 204 for success without sending any content 200 for success with a json representation of the resource And if its not a successful operation return appropriate response code. You can choose to optionally return a json. To simplify things you can have a common format (json) for all error responses.

http://en.wikipedia.org/wiki/REST is a must read before you freeze on your api specs.

Upvotes: 6

Matthew Flaschen
Matthew Flaschen

Reputation: 284927

For a JSON API I recently developed I do both. I always respond with valid JSON (well, assuming I respond at all). If I detect an invalid request, I use status 400. If I detect a server error (which I don't believe is caused by an invalid request), I use a 5xx status. The JSON object contains a special key that is only set for errors, with a string value.

I think this is a good solution that respects REST principles, and can be used in multiple ways. The same solution is used by some other JSON APIs, such as Yahoo Search. Try http://search.yahooapis.com/ImageSearchService/V1/imageSearch?appid=YahooDemo&output=json .

Upvotes: 13

Related Questions