On Mar 3, 9:42 pm, Milen <mi...@thecosmicmachine.com> wrote:
> I couldn't agree more, it's pretty lame that:
> a) the rate limit method returns incorrect results
> b) only rate limited requests return any rate limiting information
> You have a lot of situations where you firstly need to find out how
> many requests you have left and take actions accordingly, i.e. you
> need to know the rate limiting information before starting to make any
> requests that are rate limited. In any case, the status quo doesn't
> seem to be well thought through.
> On Mar 3, 3:42 pm, Ryan Alford <ryanalford...@gmail.com> wrote:
> > I just want to ask how you guys handle the following situation. And please
> > correct anything that is incorrect.
> > The user starts up your application, and they have exhausted all of their
> > rate limit(using another application). Your application does not know this
> > when it is first starting because you haven't made a rate limited request
> > yet. You now make the rate limited request, and you get the "403:
> > Forbidden" error back. I can only assume that Twitter will send the
> > "X-Ratelimit-Limit" header with the response error.
> > Does your application allow this request and then process the error, set the
> > rate limit information(you would need the date to tell the user when the
> > rate limit will reset), and go about your business? In my app, I do a rate
> > limit check before making the request(using the account/rate_limit_status
> > method). Since I can no longer do this(since that method returns 150
> > instead of 350), I was wondering how others handle this.
> > Just my personal opinion, but I think it's a horrible decision to have the
> > rate limiting headers ONLY returned for rate limited methods. This now
> > requires me to make a rate limited call just to get the rate limit, which
> > brings the previous scenario into play.
> > Thanks,
> > Ryan
> > On Wed, Mar 3, 2010 at 9:44 AM, Ryan Alford <ryanalford...@gmail.com> wrote:
> > > I was able to get that working. I didn't notice that those headers were
> > > only sent for requests that counted against the rate limit.
> > > Ryan
> > > On Tue, Mar 2, 2010 at 6:33 PM, twittelator <and...@stone.com> wrote:
> > >> I reported this bug yesterday. Instead of making that extra call, why
> > >> not look at the response headers which come back with each API ACCESS
> > >> - you'll get the info you need:
> > >> "X-Ratelimit-Limit" = 150;
> > >> "X-Ratelimit-Remaining" = 133;
> > >> "X-Ratelimit-Reset" = 1267576025;
> > >> Andrew Stone
> > >> Twitter / @twittelator
> > >>http://www.stone.com
> > >> got iPhone?
> > >> http://j.mp/twitpro
> > >> http://j.mp/tweettv-app
> > >> On Mar 2, 11:47 am, eclipsed4utoo <ryanalford...@gmail.com> wrote:
> > >> > I thought that the OAuth Rate Limit went up to 350? I am still
> > >> > getting 150.
> > >> > Here is the returned XML from my request tohttp://
> > >> api.twitter.com/1/account/rate_limit_status.xml
> > >> > <?xml version="1.0" encoding="UTF-8"?>
> > >> > <hash>
> > >> > <reset-time type="datetime">2010-03-02T19:42:28+00:00</reset-time>
> > >> > <hourly-limit type="integer">150</hourly-limit>
> > >> > <reset-time-in-seconds type="integer">1267558948</reset-time-in-
> > >> > seconds>
> > >> > <remaining-hits type="integer">150</remaining-hits>
> > >> > </hash>
> > >> > I am using OAuth and using the new "version" of the REST API. What
> > >> > else do I need to do?