Best practices for handling a web service failure

Question

In an Ajax web app, what do you do when a web service call from the browser to your server fails?

• Automatically retry, hoping it was an intermittent network failure or server error. (But when you have a real server issue, you may face further problems due to a multiplication of traffic from retries.)
• Fail, and show a message to the user like "Please try again later."

I know there's no right or wrong answer, just wondering what folks consider to be best practices.

Answer 1

Silently retry once or twice, and then fail with a warning to the user.

To avoid duplication include a unique id with each individual request, and on the server discard requests with identical ids.

Answer 2

Lately I've been using Google Docs from home. On occasion, my connection goes down for a while and then eventually returns. I like to know when the app has trouble saving (which is does at various intervals), but I'm not always necessarily concerned when it does, and I don't want a model interruption (just a message somewhere). If it's really bad (can't save for a long time), I'll just copy the whole buffer out to a notepad and save it as a backup.

That's a great example because my 'transaction' is essentially local until I need to save it. The context is on my PC for a while, then the server, then my PC again. If the app hung each time it couldn't work, I'd not be able to use it for anything non-trivial.

If the app is just a screen that accesses a server, then the local portion of it is trivial. It should keep the user informed about the current state of the 'transaction' (success or failure).

So it really depends on how much of the context is local and how much is remote ...

Paul.

Answer 3

As you say, there's no right or wrong answer, the choice has to be made depending on specific circumstances :

• A webmail polling for new messages will fail silently, retry and warn the user if the server is ureachable after a certain amount of retries (like a mail client would do)
• A page loading its content dynamically will immediatly let the user know that the content is unavailable, and why not let him trigger the retry (like any browser would do)
• etc

There's no right answer, but I think it would be a shame to be able to intercept a web service failure and then automate this bad habit users (we) have : retry, retry, retry...

Answer 4

It depends on your use case. Is failure something you can recover from? What is the expected frequency of the failure? The level of effort to "retry" the operation may outweigh the benefits. Use your knowledge of your application to determine if implementing complicated error handling is worth it... Often it is not.