With APIV1 you could make a single REST call and get all of a user's shared folder data and all of the members of each of those shared folders. Now with the new and Improved APIV2 you need to make a separate REST call for every shared folder to get that shared folder's members. So if a user has 100 shared folders the overhead went from One (1) REST call to One Hundred and One (101) REST calls - that's right, two orders of magnitude more REST calls. That is a ridiculously large overhead.
Anyway I have put threaded the calls and that saves some time. But now I'm bumping into this little problem (I think), from the Dropbox APIV2 documentation:
Rate limit errors occur when your app is trying to make more requests in a specific window of time than is allowed. There are many technical and non-technical reasons why these rate limits exist but they are set high enough such that legitimate uses of the API should rarely encounter them.
Dropbox does not/will not tell me when these limits kick in. My application checks shared folder membership every minute (remember it used to be 1 REST call a minute, NOW it's 82 REST calls a minute in this instance). So with 81 shared folders the following is consistently observed:
- 79 Folders get members: between .6 and 1.2 seconds (averaging around .7 seconds)
- 80th folder around 5.8 seconds
- 81st folder around 122 seconds
Clearly this is ridiculous, the throttling of the REST response is, for one folder, twice the interval I have available to me to get ALL folders' members' data. I am hoping there is some other reason why this is happening that I can fix, but:
Can someone confirm that this is within the bounds of reality that Rest response throttling may be occurring in this situation?
Certainly the empirical evidence suggests so.