Deprecation of following and notification elements

[Doug Williams]

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=532

Thanks,
Doug
--

Doug Williams
Twitter Platform Support
http://twitter.com/dougw