Discussing API v1.1

episod · 2012-09-05T22:05:41.000Z

At this time there’s no easy way to determine what your current token count is on an application. We’ll provide an easier way to make this determination in the future.

There’s currently no way to revoke access on behalf of your users.

episod · 2012-09-05T22:10:43.000Z

Consider that every resource in API v1.1 has changed in some way and read the documentation for the resources you make use of. In some cases the response body may have changed slightly, in other cases they have a per-endpoint rate limit defined for them that they did not have before, in some cases the resource URL itself has changed, in some cases previously available methods are no longer existant. Many changes in the API were across the board for all methods that supported entities or retweets (most objects support these). API v1.1 is a mostly new API and should be evaluated with new eyes.

API v1.1 is live. The methods documented in https://dev.twitter.com/docs/api/1.1 are the methods that exist in API v1.1 and can all be found at https://api.twitter.com/1.1/* – except for upload.twitter.com/1.1/statuses/upload_with_media.

zemaj · 2012-09-05T22:11:58.000Z

This also jumped out at me - it seems like pulling down social graph information has been severely limited for large accounts.

We’ve gone from 1,750,000 followers+following per hour to 75,000 followers + 75,000 following per 15 mins.

Is this correct?

episod · 2012-09-05T22:12:02.000Z

GETs are still easier to perform for many users. There are many use cases for all of our APIs, and while most bulk uses of users/lookup will want to use POST, there are less-heavy usages where the simplicity of a GET may be preferred.

zemaj · 2012-09-05T22:14:03.000Z

This would be really helpful

bitoclass · 2012-09-05T22:15:00.000Z

Hi, I have a question about the changes.

I currently have a subscription to the RSS feed http://twitter.com/statuses/user_timeline/bitoclass.rss, which I use to keep a local archive of all my tweets (I never think it sensible to put any data, photos or anything else only in the cloud without a local backup).

So, does your API change only affect developers, or will my end-user RSS subscription cease to work on 5 March 2013 as well?

Thanks!

episod · 2012-09-05T22:15:25.000Z

All of the rate limits are in 15 minute windows. It’s best to think of them within those groups of time instead of as hourly or minutely limits.

Unlike in API v1, all rate limiting is per user per app – IP address has no involvement in rate limiting consideration. Rate limits are completely partitioned between applications.

The Streaming API still allows basic auth. It won’t forever. Use OAuth for better future proofing.

episod · 2012-09-05T22:18:25.000Z

URLs of that style are pretty outdated now. RSS as an output format is considered part of the API, and that URL is what we consider a “version 0” URL. It will also cease functioning on March 5, 2013.

RSS and ATOM formats are relatively unused, and the OAuth requirement for all endpoints make utilizing them more difficult (or nearly impossible) for end-users. Tweets are better represented with the complete metadata available in the JSON responses available to you.

zemaj · 2012-09-05T22:29:48.000Z

On the whole these changes look pretty good. Thanks for the much friendlier wording the blog posts!

I’m a bit worried about the limitations in loading social graph data. It looks like large accounts will have to load significantly more slowly than before. The rate limitations on users/lookup also means caching will be more important that ever before for loading smaller accounts. Often users/lookup was the bottleneck in loading small accounts.

On the whole though, there are no show stoppers. The rate limiting on search is pretty exciting - making it per account based removes a lot of the uncertainty around per IP limits.

I do have one question at this point. In the Developer Rules of the Road it states “If your application will eventually need more than 1 million user tokens, or you expect your embedded Tweets and embedded timelines to exceed 10 million daily impressions, you will need to talk to us directly about your access to the Twitter API as you may be subject to additional terms.” How do we do this - who should we contact? Is there any information available about the additional terms?

Thanks Taylor.

bitoclass · 2012-09-05T22:46:05.000Z

Thank you for your quick reply, much appreciated!

Pasting the above RSS URL into a ‘subscribe to feed’ box in an RSS reader couldn’t be further from “nearly impossible” for me, and I’m an end-user. I’m not really sure what the tech jargon about “endpoints” etc means but I’m very disappointed you’re turning off this functionality.

So just to be certain I’m understanding this, the consequence is that there will from March be no way for me to subscribe to my own tweets in an RSS reader in order to keep an offline copy of them? This is literally (really) the worst news I’ve ever heard about Twitter.

Geo_Share · 2012-09-05T22:49:10.000Z

Hello,

To construct a user’s timeline up to the max 3,200 available using “statuses/user_timeline” 16 calls would be needed. (200 max returned each call) To my understanding this is now limited to 15 calls per 15 minutes. Does this make it impossible to pull down all available Tweets when first encountering a user without hitting the rate limit? What is the guidance here?

Thanks.

chockenberry · 2012-09-05T23:51:00.000Z

Thanks Taylor, looking at it in detail now.

Is the endpoint for OAuth requests still “https://api.twitter.com/oauth/”, or should this be something like “https://api.twitter.com/1.1/oauth”?

billbrown · 2012-09-06T00:13:32.000Z

Does this mean the end of the IP address-based whitelisting that was previously grandfathered? I’m referring to the 20K/hour rate that older apps might enjoy.

episod · 2012-09-06T01:12:02.000Z

Thanks, Craig. I know it’s a lot to take in and overall it’s pretty similar to 1.0 and the pre-1.0 days, but there are enough subtle differences that I think it’s worthwhile to dive in completely. Happy to help you derive any specific nuances you have questions about.

The process of obtaining authorization and OAuth token negotiation are independent of REST API versioning and you needn’t (and shouldn’t) provide a version element to the path when accessing. Stick with https://api.twitter.com/oauth/* for all of those operations whether using 1.0 or 1.1 API calls ultimately. The access tokens they yield are the same regardless.

nicatronTg · 2012-09-06T06:43:18.000Z

Perhaps I’m just being naive, but what exactly is the logic behind blocking RSS in this form? Several blogging applications rely on RSS in order to pull in Tweets (see sidebars), and RSS is the one solution that does this type of syndication in a relatively easy to manage manner.

If the goal is to prevent abuse or rate limit evasion, perhaps a delay on the published RSS feed would suffice? In the case of archival, as long as the original publication date is preserved, you could in theory not update feeds but once a day. This would prevent abuse whilst not cutting off the channel completely.

philboye · 2012-09-06T07:29:11.000Z

I think its sad, and a crazy business decision, that Twitter is removing the ability of an inexperienced developer to take some javascript and css and incorporate their tweets into a blog or website as they please. Now they must either use the cards or a much higher level of development to effectively recreate the cards because the display guidelines are so strict. This was a big part of the growth of twitter and leaves a gap for another service to fill. Instagram has to be most likely, all they need to do is create a text-only message option and will take a big slice from Twitter

Most of the api limits are not unreasonable but there are now so many rules and vague guidelines, and more will follow in the future. eg

What does “No other social or 3rd party actions similar to Follow, Reply, Retweet and Favorite may be attached to a Tweet.” really mean?

“Tweets that are grouped together into a timeline must not be rendered with non-Twitter content.” The BBC will often put tweets in a timeline of mixed content when covering sporting events. They will presumably have to remove this now and reduce the spread of tweets.

If you need to make money, just put an advert on the website, everyone else does that

PlumeApp · 2012-09-06T08:37:25.000Z

Yes, it will be easier to make business decisions if we have an idea of where we are rather than navigating in the fog

janole · 2012-09-06T08:53:40.000Z

Looking at the rate limits for lists, is it true that lists/statuses is in the 15 calls / 15 minute bucket?

I mean that way, you can only fetch tweets for one list per minute on average?

That would severely cripple the lists feature, wouldn’t it? Just imagine you’ve got more than 15 lists …

dansingerman · 2012-09-06T11:04:45.000Z

Is there a best practice way to use JSONP to make requests to API v1.1?

By playing on the command line I see adding &callback= does generate a JSONP request, but I don’t want to put all my oauth logic in Javascript (for obvious security reasons)

Also how do I send oauth headers to a JSONP request?

Help please!

episod · 2012-09-06T15:10:18.000Z

Tweets are more than the 140 character strings that make up their textual component. RSS is a great container for lightly referencing content but we prefer the full Tweet to be wherever a Tweet goes. We’ve chosen the JSON format to be our programmatic representation of tweets.