Alex agreed this makes sense. I've added this requirement to the Issue 532.
Thanks, Doug ---------------------------------------------------------------- Doug Williams | Platform Support | Twitter, Inc. 539 Bryant St. Suite 402, San Francisco, CA 94107 http://twitter.com/dougw On Wed, Apr 29, 2009 at 12:18 PM, Doug Williams <[email protected]> wrote: > Issue 532 [1] covers a friendships/mutual method that ameliorates what > friendships/exists attempts to do. On paper this appears to be a good home > for this information. Let me check with @al3x. > > 1. http://code.google.com/p/twitter-api/issues/detail?id=532 > > Thanks, > Doug > > ---------------------------------------------------------------- > Doug Williams | Platform Support | Twitter, Inc. > > 539 Bryant St. Suite 402, San Francisco, CA 94107 http://twitter.com/dougw > > > > > On Wed, Apr 29, 2009 at 10:52 AM, Craig Hockenberry < > [email protected]> wrote: > >> >> If a user has protected updates, a call to /friendships/exists returns >> a 403. That, combined with an empty or inaccurate "following" value in >> the user data returned by the API means that there's no way for a >> client to get the current following status of a protected user. >> >> (It can't be inferred by the 403 error either: the requester may be >> following, but it might not have been approved by the person being >> queried.) >> >> From what I can tell, the basic probem is that friendships really have >> three states now: following, not following and pending. It would be >> nice to have the /friendships/exists API method (or something similar) >> could provide this state so it can be represented correctly in a >> client application. >> >> -ch >> > >
