Discussing API v1.1

episod · 2012-09-07T00:47:19.000Z

I know it’s somewhat arguable, but we won’t necessarily be requiring “user authentication” on v1.1 endpoints of the API.

sferik · 2012-09-07T08:47:47.000Z

I’ve created a spreadsheet of all the resources that have been renamed or removed in v1.1. Perhaps this will be helpful to others: https://docs.google.com/spreadsheet/pub?key=0AhjQotX9U0bJdElfR01CM1ZQcHBMRXUyUHlxZFJZalE&output=html

Looking at this list, I can understand why certain resources have been removed (e.g. POST notification/follow and POST notification/leave were redundant with POST friendships/update). However, other resources have been removed with no replacement. I’m particularly disappointed to lose all the retweet resources. Will there be a way to get all the retweets by or to a particular user in Twitter API v1.1? Why was there no mention of this removal in the overview of changes?

Inbergo · 2012-09-07T13:19:20.000Z

Hello!

We are analyst team, doing some researches on public internet activity and stuff. One of many things we are interested in, is analysing particular tweet or set of tweets audience. It was easily achievable using 1.0 API /statuses/:id/retweeted_by/ids.json and /followers/ids.json resources.

In API 1.1 nor those resources neither any replacement for them are presented. Can You please suggest any official way to know particular tweet audience? Is it reasonable to ask page parameter to /1.1/statuses/retweets/:id.json resource?

Since we do non online analysis, we can try to live with lower rate limits, i.e. longer time to collect data required, but we can’t live without data itself!

Thanks and regards,
Inbergo Team.

laxkin · 2012-09-07T14:10:05.000Z

Hey twitter folks, any updates on these questions?

episod · 2012-09-07T15:10:47.000Z

Most, if not all, of the retweet timelines were duplicative sources of data available in statuses/home_timeline, statuses/user_timeline, and statuses/retweets/id – you can extract that information from those methods instead. To get all recent retweets by a specific user, you can fetch their user timeline and extract the retweets from it.

episod · 2012-09-07T15:17:52.000Z

The limits in place are meant to serve the majority of user use cases. There are some outliers that will take longer to process within these limits. Cursoring is built in a way that will be resilient across longer periods of time.

FedeASocial · 2012-09-07T15:51:25.000Z

search_metadata->next_page response contains wrong parameters:

page (invalid)
rpp (replaced by count)

due to this possible issue I can’t understand how to loop through pages and previous tweets.
am I missing something or is it a real issue?

Thanks
Fede

episod · 2012-09-07T15:55:30.000Z

You can follow along with this bug here: [node:10734]. I’m working with the engineering team to resolve and the docs will be updated with the proper metadata response portion once this is resolved. You’ll need to use since_id and max_id to move between pseudo-“pages” of results. See [node:6213] for more info on best practices in navigating timelines.

sferik · 2012-09-07T16:56:00.000Z

How would you get the equivalent of GET statuses/retweeted_to_user in v1.1?

FedeASocial · 2012-09-07T17:22:15.000Z

Understood! No more pagination!

Thanks!

digitalpoint · 2012-09-07T17:26:00.000Z

It would be helpful if there was an actual error returned in the body to clarify. For example this just returns an empty body:

curl -is https://api.twitter.com/1.1/statuses/mentions_timeline.json

jeffgreenberg · 2012-09-07T19:28:14.000Z

We ( http://tweettronics.com ) are built on 1.0, and on 1.0 assumptions since 2009. As it is we’re also grandfathered at higher limits for search which we need and want you to preserve.
1.) It sounds like you will not simply not support 1.0 but you are removing it from existence. Is that right? And if so, what are the cutoff dates and are the v1.1 endpoints fully operational now?
2.) Regarding search, i’m not clear on the limit of how many tweets we can obtain, paging or not. (We have never been a fan of the streaming API for a lot of reasons.)
Appreciate your answers. Thanks.

janole · 2012-09-07T19:58:47.000Z

You should be able to just redirect to the signed API requests from the JSON-P request to your own server.

That way the server only does the signing (shouldn’t take too much resources) and the web browser will issue the real API request to Twitter …

janole · 2012-09-07T20:02:01.000Z

Gravity is automatically fetching lists for each user you’re looking up, for example.

That makes lists a lot more interesting.

When you immediately see the lists that a user has created or is following, you get a better understanding of that user.

These kind of features won’t work with the new limits anymore, I think.

By the way, is the API 1.1 live already? Can you test it out right away?

Favstar · 2012-09-07T21:25:24.000Z

Hi there,

Currently the retweeted_by endpoint allows you to retrieve up to 800 retweeters of a tweet. It appears it didn’t make it to the list of endpoints in v1.1.

statuses/retweets/:id is in there. Is this limited to returning 100 retweeters total?

Is there still a way to retrieve up to 800 retweeters of a tweet via REST?

Thank you,
@Favstar

sferik · 2012-09-07T21:57:31.000Z

In v1, it was possible to fetch up to 100 of my tweets that have been retweeted with a single request to GET statuses/retweets_of_me.

If I’m not mistaken, the only way to do the same thing in v1.1 is to call GET statuses/user_timeline. However, there is no guarantee that calling it once will return 100 retweeted statuses (since this resource returns all my tweets, not just the retweets ones). In the worst-case scenario, I’d have to call this API 16 times to retrieve 3,200 tweets before finding the first 100 retweets.

What could be achieved in a single request now could require as many as 16, which is more than is allowed in a single 15 minute window.

I’d strongly encourage you to rethink the rate limits on GET statuses/user_timeline, GET statuses/home_timeline, GET statuses/mentions_timeline, and GET statuses/retweets/:id, since these resources are being used to replace multiple resources that existed in v1 of the API.

Also, am I correct in stating that there’s no v1.1 API replacing GET statuses/retweeted_to_user? I’m surprised there was no mention of this in the announcement of v1.1. Removing existing functionality seems like worthy of inclusion in the overview of the changes.

richardhyland · 2012-09-08T06:30:44.000Z

Yes I noticed that the retweet endpoints have gone, also that users/profile_image/ api has also gone, so the only way to get someone’s image is to call that user object instead

Ben_Steffens · 2012-09-08T14:49:03.000Z

Hello,

I was wondering whether applications that combine services will be at all effected given they follow the rules of the roads?

Our service combines Facebook and Twitter (and soon Instagram). The feeds, messages and notifications are merged into single feeds. This is not a traditional client and it doesn’t seem to go against any of the rules any more… but I just wanted to check to make sure?

Cheers!

mrcfield · 2012-09-08T21:39:38.000Z

Have the daily (trends/daily.json) and weekly (trends/weekly) trends endpoints been removed?

FlockOfBirds · 2012-09-09T11:37:56.000Z

So if I understand you correctly, whitelisting will disappear in 1.1? If so, I would love to know how to get elevated access for certain API calls.

For my application (and I assume numerous others), whitelisting/elevated access rate is crucial, as the API endpoints and rate limits are tailored towards certain use cases like clients or Tweet analysis tools. And if a tool does something else (in my case network analysis/management), the API endpoints and rate limits simply do not fit.

For example, if a network analysis needs the following lists of all the people a user follows and you would like to generate an answer in the minute range, it would work

with whitelisting for all but the biggest accounts (up to 19,798 following)
with 1.0 limits only for quite small accounts (up to 345 following)
with 1.1 limits for almost no account (up to 14 following)

A couple of things that could help here:

The obvious one: Whitelisting as before.
Whitelisting the friends/ids and followers/ids calls only.
An endpoint allowing to batch retrieval of following/follower id lists (like users/lookup for users). It would be OK if this one would only work for cursor=-1.
Making the time window a lot bigger for friends/ids and followers/ids. For a network analysis, it is often fine to cache data for a week or so, as following lists do not change much over time. But to collect the data takes way too long with a 15 minute window. If an app could make a week’s worth of calls for a user in a minute, it could then cache it and do analysis based on that data for the next week.