Currently Fitbit has a per-user "rate" limite of 150/hr. Since the hourly quantum is big, it is truely viewed as a "quantity limit". The distinction between a "rate" limit and "quantity limit" stems from the fact that servers are more able to handle larger quntities of uniformly spaced loads than bursty loads. This would allow the "rate" limit to be greater than the current value of once every 24 second of uniform load and is easier to manage proactively in the client than an hourly "rate" limit. Let me give an example.
Currently one way to proactively manage the 150/hr limit is to optimize the number of fitbit calls, burst w/o any limits and hope you don't exceed it. The other way is to emit a call and wait 24 seconds or a variation thereof which willl change the waiting time as we approach the limit. This requires keeping cumbersome, per-user static state on the *disk* or another database (since many programs complete in a few minutes as opposed to hour or more) for backend programs.
Now most APIs have a higher "rate" limit (100 calls/second) and a daily limit (5000 etc.) and these limits depend upon how much you pay of-course. Let's assume that Fitbit is a free API with no plans to charge and has greater volumes, so we have 2/second rate limit 100 calls/10 minutes quantity limit (reflects the fact that uniform loads are better than bursty). In that case, a programmer can put 500 miliseconds delay after every call and if he knows the program runs more than 50 seconds, maintain an in-memory ( as opposed disk or database based) static state.
Is there a plan for implementing anything like this rate and quantity limit that is the norm with many other APIs?
