Issues 419 [1] and 474 [2] are very popular, in the painful kind
of way. The defects report that methods returning user
objects (see users/show for an example [3]) are returning incorrect or
invalid values for the <following> element.
The fix for this inconsistency is in fact non trivial [4]. The
problem lies within the interaction of the application logic, caching
layer and database design. The persistent data behind <following>
and
<notification> values are separate from the user data in our
architecture, so to keep these elements valid in cache alongside user
objects adds a large amount of complexity.
Developers made it obvious that these data are a priority and we
want to ensure they available. We also want to guarantee they are
accurate and that performance remains good. Given the problems
explained above, we are going to be making a number of changes to the
API so that you can rely on the <following> or
<notification> data.
Deprecations:
The following elements are to be removed from all returned user objects returned by the API:
1) <following>
2) <notifications>
This deprecation will not occur until we finish the following:
Additions:
To continue to provide access to this data we will be creating a new method:
Issue 532 [4] outlines the need to perform a mutual following lookup.
We will use a method similar to that described in this issue to deliver
<following>, <followedby>, <notification> and
<pending> (in the case of protected users) data with a single
call.
We realize this change will cause an increase in API usage for some
applications. Therefore we are going to increase the default API rate
limit across the
board. This should help absorb some of the costs for applications
attempting to do interesting things with social graph data. The number
will be somewhere between 101 and
200 calls but we still need to look
at growth projections and current hardware
capacity before settling on a definite number.
We plan to begin work on
this relatively soon with the fix coming in a few weeks. We do not have a planned ship date at this time but will communicate specifics with
developers as they are determined. We anticipate the new number of calls and a documented schema for the new method will be made available before the new method ships.
Please watch this thread and @twitterapi for the incremental details.
1.
http://code.google.com/p/twitter-api/issues/detail?id=419
2.
http://code.google.com/p/twitter-api/issues/detail?id=474
3.
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show
4.
http://www.jamesshuggins.com/h/tek1/first_computer_bug_large.htm
5.
http://code.google.com/p/twitter-api/issues/detail?id=532Thanks,
Doug
--
Doug Williams
Twitter Platform Support
http://twitter.com/dougw