Timeline for Request Throttling Limits
Current License: CC BY-SA 2.5
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 20, 2010 at 4:25 | comment | added | Sky Sanders | @kevin - perfect - that is exactly what I was hoping for. | |
| Jul 20, 2010 at 4:22 | comment | added | Kevin Montrose | "The exact manner in which this constraint is enforced can vary over time" means that the API will respond however we feel like if you break the request spacing invariant. This could be a 503, it could mean we just close the underlying TCP connection. Any response is a "correct" one. Of course we aren't going to change the "30 over 5" part, as that would defeat the point of spec'ing it in the first place. | |
| Jul 20, 2010 at 4:20 | comment | added | Kevin Montrose | "30 requests over 5 seconds" is exactly what I mean. 30 requests within 5 seconds, clustered however. That could be 1 every 6th of a second, or 30 right up front. | |
| Jul 20, 2010 at 3:58 | comment | added | Sky Sanders | @jjn - don't forget a min 60 sec cached buffer - it does wonders for responsiveness and throttle compliance | |
| Jul 20, 2010 at 3:47 | comment | added | jjnguy | @code, I am happy...and relaxed...and gonna look into creating a throttled queue for my api. | |
| Jul 20, 2010 at 3:36 | comment | added | Sky Sanders | @jjn - we may have different ideas of how a library should abstract details like this away from the casual or hobbyist consumer, but in any case, I have already implemented a throttled queue as well as request caching in all of my libraries, which is not trivial if to be done properly, and just need some clearly defined numbers to plug in to them. An interval of 170ms does indeed seem to be the magic number and is actually much better than I was expecting. I am happy. Are you happy? YAY! everyone is happy and can relax. | |
| Jul 20, 2010 at 3:26 | history | edited | Sky Sanders | CC BY-SA 2.5 |
added 613 characters in body
|
| Jul 20, 2010 at 3:13 | comment | added | jjnguy | (cont) In that case, make sure you wait 1/6 of a second between requests. | |
| Jul 20, 2010 at 3:13 | comment | added | jjnguy | @code, also to this point - "We must construct our client libraries to respect the throttle while providing a nominal request rate and these numbers are crucial to that end, otherwise the apps that are built on them will be brittle." I don't think it is our job to provide throttling in the library. Unless you provide some library call that has the potential of making multiple calls to the api. | |
| Jul 20, 2010 at 3:11 | comment | added | jjnguy | @code What I'm against is wasting the devs time on an unnecessarily complex specification. | |
| Jul 20, 2010 at 3:08 | comment | added | Sky Sanders | @jjn - are you somehow opposed to a formal spec that can be codified and complied without ambiguity? | |
| Jul 20, 2010 at 3:00 | comment | added | jjnguy | It should be pretty simple. If at any time you have made more than 30 requests within 5 seconds, you have violated the terms of using the api. | |
| Jul 20, 2010 at 2:42 | history | answered | Sky Sanders | CC BY-SA 2.5 |