In accordance with our previous announcement, we have completed the change
to Search API rate limiting response code. This change allows downstream
systems to more appropriately respond to rate limiting. The original
announcement follows:
We're changing the response code sent back by the Search
On December 22, 2009 we announced that the social graph method pagination of
the followers/ids and friends/ids would finally be removed. We announced
deprecation in September (http://bit.ly/46x1iL), November (
http://bit.ly/3UQ0LU) and December (http://bit.ly/5VPWk7) of last year. The
page
or no?
Thanks
Simon
On Jan 6, 8:15 pm, PJB pjbmancun...@gmail.com wrote:
Can we please get some confirmation that the cursor-less calls won't
be going away this coming Monday?
On Dec 22 2009, 4:13 pm, Wilhelm Bierbaum wilh...@twitter.com wrote:
We noticed that some clients are still calling
pm, Wilhelm Bierbaum wilh...@twitter.com wrote:
We noticed that some clients are still calling social graph methods
without cursor parameters. We wanted to take time to make sure that
people were calling the updated methods which return data with cursors
instead of the old formats
next_cusor and
previous_cursor strings. Is there really a use case
for having to return them as JSON ints? Most of the time they get
converted to strings and appended onto the API requests.
Josh
On Tue, Dec 22, 2009 at 6:54 PM, Wilhelm Bierbaum wilh...@twitter.com wrote:
Sorry, I had
We're changing the response code sent back by the Search API when the
rate limit has been exceeded. At present, it is impossible to
distinguish rate limit responses from other error conditions in
responses from the Search API -- this is what we're trying to fix.
Starting Monday, January 18th,
-1300794057949944903/previous_cursor
/id_list
or, the JSON equivalent:
{ids:[1, 2, 3], next_cursor:0, previous_cursor:0}
If you have any questions or comments, please feel free to post them
to twitter-development-talk.
Thanks!
--
Wilhelm Bierbaum
Twitter Platform Team
different codes indicating that
the limit is exceeded...
2009/12/23 DustyReagan dustyrea...@gmail.com
Will you be changing the REST API error code to match the Search API?
RE: 420 = rate limit exceeded.
On Dec 22, 4:44 pm, Wilhelm Bierbaum wilh...@twitter.com wrote:
We're changing
with cursors.
If you have any questions or comments, please feel free to post them
to twitter-development-talk.
Thanks!
--
Wilhelm Bierbaum
Twitter Platform Team
, please feel free to post them
to twitter-development-talk.
Thanks!
--
Wilhelm Bierbaum
Twitter Platform Team
, this code will have to
change soon. We're considering feedback we've received to figure what makes
the most sense. We will be announcing the change to another 400-series error
code when it is apparent what is best.
Thanks,
Wilhelm Bierbaum
Twitter Platform Team
On Wed, Dec 2, 2009 at 7:32 PM, Wilhelm Bierbaum wilh...@twitter.comwrote:
Your observations are correct. Ordering cannot be guaranteed because
of the way we store the graph. I'll make sure that we update the
documentation to reflect this fact.
On Dec 2, 7:45 am, tom tswool
the disconnect?
Thanks,
Tom
On Wed, Dec 2, 2009 at 7:32 PM, Wilhelm Bierbaum wilh...@twitter.comwrote:
Your observations are correct. Ordering cannot be guaranteed because
of the way we store the graph. I'll make sure that we update the
documentation to reflect this fact.
On Dec 2, 7:45
Your observations are correct. Ordering cannot be guaranteed because
of the way we store the graph. I'll make sure that we update the
documentation to reflect this fact.
On Dec 2, 7:45 am, tom tswool...@gmail.com wrote:
Hi All,
We've recently seen a change in the ordering of the users that the
As previously announced by Alex Payne on September 24th (see
http://bit.ly/46x1iL), we're removing support for pagination from the /
friends/ids and /followers/ids methods.
As of that time we set a hard deadline of October 26th, 2009. The
original date has passed as we tried to give all of our
15 matches
Mail list logo
