API Communications - Best Practices
Dialing... busy... retrying... dialing... Remember the days of dial-up internet? The ever-so-common scenario where you heard a busy signal. As frustrating as this was, the great part was your mode...
Forum Discussion
First of all thanks for top posting on a technical topic. Having QuickBase staff share original information like this is helpful to the community to better understand features, best practices and your design rationale.
However, I am not entirely certain of the context and specific reason this topic was addressed. I suspect it has something to do with recent questions or incidents related to webhooks, actions, automation that involve calling the QuickBase API from third-party servers.
I make the distinction of "calling the QuickBase API from third-party servers" because my experience is that "API retries" are almost never needed when using the QuickBase API from code pages saved within QuickBase.
My argument is simple: Code pages containing JavaScript (which make API calls) are loaded on top of native QuickBase pages and it would be very unlikely that network conditions allow the successful load of the native page and then immediately deteriorate just prior to the loading of the code page.
You of course can code "API retries" into your JavaSript if you want. Here is one approach:
Answer: What's the best way to retry an AJAX request on failure using jQuery?
https://stackoverflow.com/questions/10024469/whats-the-best-way-to-retry-an-ajax-request-on-failure-...
If you use the above technique you wind up writing a lot of extra code for every API call which will rarely if ever be invoked. In almost 20 years of using QuickBase I have never had to use "API retries" from JavaScript served from code pages.
However, I am not entirely certain of the context and specific reason this topic was addressed. I suspect it has something to do with recent questions or incidents related to webhooks, actions, automation that involve calling the QuickBase API from third-party servers.
I make the distinction of "calling the QuickBase API from third-party servers" because my experience is that "API retries" are almost never needed when using the QuickBase API from code pages saved within QuickBase.
My argument is simple: Code pages containing JavaScript (which make API calls) are loaded on top of native QuickBase pages and it would be very unlikely that network conditions allow the successful load of the native page and then immediately deteriorate just prior to the loading of the code page.
You of course can code "API retries" into your JavaSript if you want. Here is one approach:
Answer: What's the best way to retry an AJAX request on failure using jQuery?
https://stackoverflow.com/questions/10024469/whats-the-best-way-to-retry-an-ajax-request-on-failure-...
If you use the above technique you wind up writing a lot of extra code for every API call which will rarely if ever be invoked. In almost 20 years of using QuickBase I have never had to use "API retries" from JavaScript served from code pages.
