You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
nasa / api-docs Public
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
This is hard to explain .
This weekend, there were obviously some sort of connection issues to the APOD api endpoint. I was a bit perplexed as to why my app failed to deal with this issue. My AJAX requests use promises to deal with both successful and failed http get requests to the APOD api.
So I logged the response from api.data.gov to my console, and it was clear: a "failed" connection to the APOD endpoint looks like it is detected by something called a HTTPConnectionPool, which redirects the request (or is a result of redirection itself). This results in a "successful" connection and a response with a JSON payload with error and message (Admins have been notified) properties.
That is why my app failed! The AJAX request was not allowed to fail! That is a problem, IMHO . at least from a JavaScript/AJAX/Frontend developer perspective. Had the request just failed to connect at all, my app would have immediately responded, alerting the user to the failure. Since the request did not, could NOT fail, then my app tried to process the JSON payload as if it were a regular, successful JSON data response from APOD. Well, that meant I had to rewrite the app to check for an "error" property in the JSON response, and deal with it accordingly rather than relying on the AJAX promise handler.
This has a negative side effect in that it takes a LONG time for the response to return to the app! And, IMHO, is probably putting an unnecessary load on the backend infrastructure. I could be wrong about that, though. It certainly is unnecessary, from my perspective, to receive any info about a failed resource. It just needs to fail to connect. THAT, I can deal with! It is much faster and more efficient from a frontend perspective to deal with a refused/failed connection, than to deal with a successful but wrong connection!
In other words, a failed connection is generic, thus efficiently dealt with via promises on the frontend. A successful but wrong connection (i.e. a request to one resource that leads to a response from a different resource) makes dealing with the error very difficult since it makes frontend promises irrelevant. And figuring out the format of the JSON "failure" response, and what to do with it, may require a case-by-case analysis of each resource to figure out what "failure" means, as opposed to a generic connect failure.
Long story short: If I had my druthers, I would rather get a failed connection, full-stop, than a successful connection (that I don't want) telling me that what I wanted is unavailable. Does that make sense? :) Outage info could be posted elsewhere.
I hope not TLDR!
The text was updated successfully, but these errors were encountered: