I agree with Chad: explicitly stating the source and target in the
attribute name makes it much clearer. It also has a side benefit of
bringing the information you need most (for a UI) to the top of the
results hierarchy.
-ch
On Jun 9, 10:52 am, Marcel Molina mar...@twitter.com wrote:
Thanks
In thinking this through a little more and how this would fit into my
applications, I have another suggestion to propose.
Currently, if an application requests the followers of user B, on
behalf of user A (i.e., the request is authenticated with user A's
credentials), it gets back the list of
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
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
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),
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,
Thanks for adding the extra verbiage.
However, I'm still not clear how to decipher the exact relationship
given the data. In the example, is Bob following Jack? ...or is Jack
following Bob?
-Chad
On Tue, Jun 9, 2009 at 1:12 PM, Doug Williams d...@twitter.com wrote:
Thanks, Chad. I've
Hey Chad, thanks for your feedback.
Thought experiment: Put aside the currently proposed response body for
the moment. How would you unambiguously express the following/followed
by relationship?
Marcel Molina
Twitter API Team
http://twitter.com/@noradio
On Jun 9, 10:23 am, Chad Etzel
Hi Marcel,
Welcome to Twitter, btw (if I'm allowed to say that).
One unambiguous way might be:
{relationship: {
source: {
id: 123,
screen_name: bob,
notifications: false },
target: {
id: 456,
screen_name: jack,
notifications: null },
source_follows_target: true,
Thanks for the suggestion Chad.
What do others think of
{relationship: {
source: {
id: 123,
screen_name: bob,
notifications: false },
target: {
id: 456,
screen_name: jack,
notifications: null },
source_follows_target: true,
source_followed_by_target: false
}
}
versus
If you're going to redefine the way that follow information is
returned, I believe that it should include the effect of protected
accounts on both sides of the follow equation.
Thanks,
-damon
--
http://twitter.com/damon
On Tue, Jun 9, 2009 at 10:52 AM, Marcel Molinamar...@twitter.com wrote:
It seems from the examples, but not explicitly stated anywhere, that
the values of the following and followed_by items are booleans,
implying that a user either is or is not following another user.
While at first blush that seems true, I think in reality the situation
is a little more
Good point about pending requests for protected accounts and the opportunity
to get parity.
My inclination is rather than overloading following and followed_by that we
potentially introduce a 'pending' attribute that is either true or empty.
Similarly we could add a 'blocked'/'blocked_by'.
These
Though, it should be mentioned, w/r/t/ to pending follow requests and
blocks, you'd only get a value for those attributes for authenticated
requests where the source user is authenticated.
On Tue, Jun 9, 2009 at 5:22 PM, Marcel Molina mar...@twitter.com wrote:
Good point about pending requests
If adding the other states (pending, blocked, etc) then I would agree
with the redundancy by having all attributes present in both
source and target objects. These relationships are not
necessarily symmetric, so it makes sense to have them in each object
since they would not necessarily be
15 matches
Mail list logo
