Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Suppose a web application relies heavily on the third party APIs and I am expecting a response from it but somehow I don't get any, maybe because of the API exception or missing value on the API side then, in that what should I do?
As far as I can understand if I get the API exception I can catch it and send some error message as a response but what if I don't get any value from the API? what should be my response? error? or some default value?
What is the recommended practice?
If you're giving flow of control to the API the response is to wait until hell freezes over, or the user presses ctrl-alt-del. If you're calling it asynchronously the typical strategy is to timeout.
If the API throws an exception, easy: clean up, log, and display the error.
Whatever you do, don't fail quietly. I hate debugging things that fail quietly.
If the API returns but hands you nothing, that is, null or nil, well that means whatever the API documented that to mean. Null is overloaded to mean many things. It is a gaping hole in the typing system. Sir Hoare called it his billion dollar mistake.
When you ask for something you are making a query, that is, asking a question. Every question has a premise. Something it assumes to be true. When that assumption is wrong we respond with something other than was expected. We may be in a system that assumes it can ask for the height of anything and find ourselves modeling a song. When asked the height of a song how can you respond? Make up some amplitude nonsense and stick it in a height object? We usually respond with an exception, an error code, a NaN, or in some sad cases, with a null. Each API will have already made this decision. Whatever they did, if it violates the expectations of the question just please, don't fail quietly. Give some idea what might be wrong. Even 404 is better than a blank page.
If you can't rely on the 3rd party API to give you a response (and you're accessing it synchronously) you can set a time-out. I would access the 3rd-party API on a separate thread (or even process) and wait for the response with a time-out set. If the time-out expires, just move on.
Additionally, I had a very similar problem a while back. Feel free to check it out:
Avoiding hangs when calling an API.
In my case, the API was 3rd party Windows native DLL written in C++. It won't matter that your API is not a native Windows DLL, you can still employ some of the strategies that people suggested as answers. Hope everything works out for you.
I don't think there is a definite right answer. It depends of course. If I were you I would think about what the ideal user experience would be when this happens. Then do whatever it takes in your application to make that happen.
You could just throw an error and tell the user to try again later. Or if it's an issue that happens sporadically, just retry the request again for them. Just be sure to let them know that you're working on getting the data for them and it's taking longer than usual. Whatever you do don't mislead the use and don't just leave a spinner on the screen there indefinitely.
When you call an API through https, you can get the following answers: Internet is down. Cannot connect to the server. https failed to negotiate (after reaching the server). A nonsense answer when you use http in a Starbucks. The server tells you that the API is currently down. The API tells you that it isn't working right now. The API gives one of many status codes that indicate something went wrong. The API gives you a status code indicating it has a reply, but the reply looks wrong. The API gives you a status code indicating it has a reply, and the reply looks right.
Some things indicate errors in your code, so you fix them. Some things indicate errors in the API code, so you ask someone to fix them.
Apart from that, if you don't get a good answer, you need to think hard about what is the most useful thing to tell the user. If there is something the user can do to fix the problem (which may be "try again later", or "call your help desk", or "turn your network on"), tell them. If there is nothing they can do, do whatever is most helpful.
