first of all, let me say that I think this change to the relation between
the retweet and the retweeted status makes much sense - it feels much more
natural to see it as "user A retweets user B" instead of "user B retweeted
by user A", especially if you don't follow B.

A couple of questions inline below:

2009/10/1 Marcel Molina <mar...@twitter.com>

> After experimenting with this approach we've decided that it's a
> better bet to craft a payload that will degrade far more gracefully.
> So we've redesigned the retweet payload. Rather than having the
> original tweet as the top level status with embedded details about who
> retweeted it, the retweet is the top level object and within it we
> include the original tweet and its author.

In your original design, the retweeted message was about to appear in a
user's stream, by the original author. I understand that one of the main
objectives of this change was to avoid the confusion of people appearing in
home timelines that users aren't following. Does that also mean that you'll
now show the retweet as sent by the retweeter, not the original poster, and
give credit to the original poster in the meta information for a tweet on
your web interface? (kind of the opposite of what the first version did)

> You'll have full access to
> the entire retweeted status and user as well as the original tweet and
> its user. So you don't have to make any additional API calls and
> should have everything you need to display a retweet distinctively
> with attribute to both the original author and the retweeter.

Are you considering a retweet as a single entity, or as part of a number of
retweets of the original message? In other words, is the "an by 5 others"
(if multiple people retweeted a message) still something you want to show
somehow? If more than one of my friends retweets a message, should this be
displayed as multiple messages now, coming from different people, or are you
still collapsing retweets? (the latter doesn't make much sense anymore IMO,
as with the inverted relation, the retweet is now coming from the retweeter,
not the original poster anymore)

> In other
> words, these retweeted statuses look a whole lot like regular
> statuses. This new design was our instinct to begin with and we
> probably should have gone with it. We think it's better and hope you
> do too. All the same documented resources will exist. Only the
> payloads change.
The /statuses/retweets/id.format endpoint returned a list of retweet_details
before - as I understand it, this data structure no longer exists. What will
it return instead?

> The following timeline should contain examples of the updated retweet
> payload. You can use this to test consuming retweets.
> curl http://twitter.com/statuses/user_timeline/testiverse.xml
> curl http://twitter.com/statuses/user_timeline/testiverse.json
> In the event that new tweets go into the above timeline that push the
> retweets out, you can access a few directly at the following urls:
> curl http://twitter.com/statuses/show/4452134416.xml
> curl http://twitter.com/statuses/show/4452466408.xml
> curl http://twitter.com/statuses/show/4349744308.xml
> The above payloads don't contain a "retweet_count" element yet and
> they probably will. Other than that we don't suspect any more major
> changes as we approach a full public launch. As always, though, we're
> open and solicitous of everyone's feedback.
If there is no retweet_count, how can apps know if they need to display
something like "and by 5 others"? How can they know if it is worth
requesting a list of retweets (doesn't make sense if there is just one
retweet, as it would waste an API request)? Or (see question above) is
showing the list of retweets considered a deprecated feature?

> Thanks.
And finally: when will the retweet API be available for beta testers again?


>  --
> Marcel Molina
> Twitter Platform Team
> http://twitter.com/noradio

Reply via email to