Thanks, Chad. I've augmented the usage notes section to explain the
rationale behind the denormalized and redundant data.
Thanks,
Doug
On Tue, Jun 9, 2009 at 9:47 AM, Chad Etzel <jazzyc...@gmail.com> wrote:
>
> Taking a look at the json return example:
> {"relationship": {
> "source": {
> "id": 123,
> "screen_name": "bob",
> "following": true,
> "followed_by": false,
> "notifications": false },
>
> "target": {
> "id": 456,
> "screen_name": "jack",
> "following": false,
> "followed_by": true,
> "notifications": null }
> }
> }
>
> In the "source" object (i.e. for "bob"), "following" is true. Does
> this mean that Bob is following Jack, or vice-versa?
>
> Knowing that, the other 3 following/followed_by value meanings can be
> properly inferred. Some clarification on the page would help.
>
> -Chad
>
> On Tue, Jun 9, 2009 at 12:40 PM, Doug Williams <d...@twitter.com> wrote:
> > That makes things difficult. Permissions are now public.
> > Thanks,
> > Doug
> >
> >
> >
> >
> >
> > On Tue, Jun 9, 2009 at 9:39 AM, Chad Etzel <jazzyc...@gmail.com> wrote:
> >>
> >> <qoute>
> >> Access Denied
> >>
> >> You don't have permission to look at Twitter REST API Method:
> friendships
> >> show.
> >> </quote>
> >>
> >> :)
> >> -Chad
> >>
> >> On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams <d...@twitter.com>
> wrote:
> >> > We discussed the need to deprecate the <following> and <notifications>
> >> > elements [1] a few weeks back. We have begun work on the
> >> > friendships/show
> >> > method as mentioned in the notice. The method is slightly out of our
> >> > conventional design, so we are soliciting opinions on its fitness for
> >> > general use-cases. Please peruse the purposed method's documentation
> [2]
> >> > and
> >> > let us know what you think.
> >> >
> >> > 1.
> http://groups.google.com/group/twitter-development-talk/browse_frm/thread/42ba883b9f8e3c6e
> >> >
> >> > 2.
> http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show
> >> > Thanks,
> >> > Doug
> >> >
> >> >
> >
> >
>
