2

Given a REST API, which throws an exception when handling a request from a client. Whenever the REST API throws an exception, it's logged and the application (in this case a console application) closes to prevent further damage.

Should I send a response to the client whose request resulted in an exception, indicating that an error occured or should I let the client hang and deal with it (timeout)?

9

I've never seen any API letting the client hanging in a case of an error. Unless you have a very specific case where this makes sense¹ This simply doesn't make sense, and such behavior would only result in a practically unusable API:

  • This would slow the development of the client applications. Unless I read very, very carefully the documentation (and the documentation is excellent), I'll make mistakes which would result in timeouts, and thus slow development.

  • This would also make the client apps slow if they cause exceptions when used by an end user.

So no, don't do that.

What you should do is to handle the error gracefully. This means sending a response containing:

  1. A specific HTTP code, like 404, 403, 500, etc.

  2. The detail explaining what happened. Usually, this shouldn't be the exception itself, since it may contain sensitive information and you may want to provide something more understandable to your users.

  3. Eventually the internal code. This may help when providing support. “I tried to access the list of products and got the error 7016.” is shorter to tell to the support than “I tried to access the list of products and got the error ‘The category is missing in the request. When querying for the list of products, the category should be provided.’”.

  4. Eventually the link to the web page of your website which contains additional documentation, examples and workarounds.

Example:

HTTP 404
{
    "error": "The category is missing in the request. When querying for the list of products
, the category should be provided.",
    "code": 7016,
    "help": "http://api.example.com/docs/errors/7016"
}

The http://api.example.com/docs/errors/7016 page explains further how to avoid this error, i.e. what GET or POST parameter should be used in the request to specify the identifier of the category.


¹ I can imagine two cases: a super-secure API which needs to prevent its users from trying to break it and an API which wants to prevent DDOS. In the first case, it looks like a weak way to protect anything. In the second case, hanging without answering won't prevent the client from sending other requests meanwhile.

  • 1
    It's usually better to allow clients to fail quickly, unless you have reason to think the failure is the result of some sort of malicious request. Allowing clients to hang until they time out can consume resources, frustrate users, etc., etc. – TomG Apr 29 '14 at 2:17
  • Actually you would be much better off letting bad request fail quickly -- hanging them creates a nasty ddos vector, web servers don't like stuck processes whereas clients can easily choose to fire and forget allowing them to create many, many hung processes. If you are looking at flood control or to prevent brute force attacks on secrets there are much better options. – Wyatt Barnett Jul 25 '14 at 13:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.