Yea, I understood the differences. My question was why are there different response codes for the same result? I can understand the 503 being inherited from Summize. However, the 400 vs 403 seems like poor planning when building out the API. Is there a chance or are there any plans to unify the response codes to make more sense?
On Oct 5, 6:48 pm, Chad Etzel <c...@twitter.com> wrote: > Hello, > > On Mon, Oct 5, 2009 at 8:53 PM, jmathai <jmat...@gmail.com> wrote: > > > Why are 400, 403 and 503 valid response codes to signify that a call > > is being rate limited? Was there a dart board involved? > > I don't know, but it would be really hard to play 301 with that dartboard. > > > > > * 400 Bad Request: The request was invalid. An accompanying error > > message will explain why. This is the status code will be returned > > during rate limiting. > > This is for hourly rate limits for GET requests. 150 req/hr for the > normal case (20k req/hr for whitelist). > > > * 403 Forbidden: The request is understood, but it has been > > refused. An accompanying error message will explain why. This code is > > used when requests are being denied due to update limits. > > This is for daily update limits (POST requests: sending tweets and > DMs, following people, etc). > > > * 503 Service Unavailable: The Twitter servers are up, but > > overloaded with requests. Try again later. The search and trend > > methods use this to indicate when you are being rate limited. > > This is a hold-over from when Twitter Search was Summize. I expect > if/when the Search and REST APIs merge into a single API that this > rate-limit code will be 400 instead. > > -Chad
