###Update:
<strike>I am unable to reproduce the case of interactive browsing affecting app quota. And will concede that the failures that prompted this post were likely far edge cases.

The remaining issue of a badly behaved app failing and thus inducing a browsing DOS is not a bug in the throttle, simply a consequence of running a badly behaved (designed) app.

It was the other way around that concerned me i.e. interactive browsing eating app quota and inducing an all-around DOS.

I am not yet completely convinced that this is not a possibility, but until the throttle rate issues is cleared up, it is near impossible to write a test that can get reproduce what is admittedly and edge case (i hope).
 </strike>


The new throttle does not differentiate between programmatic API requests and requests made by a browser while viewing a Stack Exchange site.


This is a *very* serious issue.

The implication is that every app written against the API must warn the user not to view any Stack Exchange site while using (or x number of seconds before or after starting) the app or complete app and browsing failure could result.

Given the 'if you violate the throttle you, the response is undefined as are the consequences which could include being banned for an indeterminant period of time' (paraphrased, correct me if I am wrong) specification, this is best avoided.

Some have gone to extraordinary lengths to comply with the published throttle guidance, which I am not sure is yet accurate, and to lump the end-user's browsing activity in with the throttle quota is an impossible criteria to manage.

This behaviour was introduced with the new throttle and I can only assume that this is an oversight and hope that it will be resolved.


The obvious solution is to separate http://api.xxxx and http://xxxx requests from each IP into distinct quota buckets.

###Repro 

This issue can be reproduced by browsing a stack exchange site while running the [throttle tests][1] I have made available. 

Granted, you will probably have to browse fairly quickly to ensure a failure in this test, but the point is that if an app is in the middle of a burst, say polling your (or your users) accounts and checking for data on those accounts, which most apps do, meanwhile you (or your users) are browsing a stack exchange site there is a possibility that a total DOS will occur.

Again, let me stress that is is not an issue of squeezing every single possible request per second from the API. It is about having a clearly defined specification that can be relied upon. 

Lumping API traffic in with browsing traffic over which the developer has no control presents an unmanageable criteria.






  [1]: https://stackapps.com/questions/1457/api-usage-triggering-503-too-many-requests