After 5-8 successful requests 503 error, in html format, are being thrown.
The requests are unique and consecutive, no api abuse is occurring.
A related, but critical, concern is that any error raised as the result of a JSONP API call needs to be JSON with a 200 status, not HTML. We covered this in this issue: API Suggestion: suppress http error code when jsonp is specified
see all api endpoints except api.stackoverflow.com are failing paged requests with HTML 503 for related bug.
Update 1:
Tests show that the introduction of a delay of 300ms between requests bypasses the throttle guard on /users/{id}/associated. I suspect that this will be the case for all api endpoints except api.stackoverflow.com are failing paged requests with HTML 503 as well.
While this could be considered a workaround, it adds unnecessary complexity and exception handling, especially in asynchronous scenarios and affects responsiveness of applications.
Update 2:
I am being told by the stack overflow team that they feel throttling is working as expected. I can't argue with them about the interval they choose to use as a throttle threshold, although the fact that api.stackoverflow seems to treat api requests 'properly', e.g. servicing consecutive unique requests without complaint, while all other sites do not would indicate that perhaps someone, somewhere at some time understood that an api is consumed programmatically. Or it could just be coincidence.
What I can complain about is that I am not sure that they realized that the behavior of sending HTML 503 breaks JSONP clients. If they were to send a JSON formatted error with a status of 200 when JSONP is specified, we could capably handle the error, compensate and adjust the request rate. As it is, things just fall apart.
I can also complain that there is no published threshold interval. How can we comply with a throttle threshold if we don't know what it is? Take a guess, fire some requests being ever vigilant for 503 (unless you are using JSONP, then you are SOL) and then take another quess? Does anybody realize the amount of complexity that introduces
The bottom line, really, in my opinion, is that API requests are controlled via rate limits and as long as they are not representing polling abuse, e.g. identical requests within a minute of each other, which is easily handled with a caching buffer built into the library, they should be serviced without complaint, as they are by api.stackoverflow.com and as stated in Conscientious use of the API
....... GET /0.9/users/01b106cc-dc85-4f3c-a9af-3abfd2fc86a3/associated?key=[my key]&jsonp=Soapi._internal._callback144 HTTP/1.1 Accept: */* Referer: http://localhost:23616/src/UserSearchAutocompleteJQueryUI.htm Accept-Language: en-US User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; Tablet PC 2.0; .NET4.0C; .NET4.0E) Accept-Encoding: gzip, deflate Host: stackauth.com Connection: Keep-Alive HTTP/1.1 503 Service Temporarily Unavailable Server: nginx Date: Wed, 07 Jul 2010 22:52:22 GMT Content-Type: text/html Content-Length: 650 Connection: keep-alive ------------------------------------------------------------------ GET /0.9/users/5627464e-02dd-4078-8594-00fff4c8a317/associated?key=[my key]&jsonp=Soapi._internal._callback145 HTTP/1.1 Accept: */* Referer: http://localhost:23616/src/UserSearchAutocompleteJQueryUI.htm Accept-Language: en-US User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; Tablet PC 2.0; .NET4.0C; .NET4.0E) Accept-Encoding: gzip, deflate Host: stackauth.com Connection: Keep-Alive HTTP/1.1 503 Service Temporarily Unavailable Server: nginx Date: Wed, 07 Jul 2010 22:52:22 GMT Content-Type: text/html Content-Length: 650 Connection: keep-alive .......
