Discussing API v1.1

waggydogtail · 2013-01-04T04:21:09.000Z

Thanks for you quick response!!
I shall look into using the streaming API if we are to do any future enhancements.

click_tony · 2013-01-07T17:55:41.000Z

Hey @episod,

There are mentions here and there about the ‘userless’ or application-only authentication context being rolled out in ‘the coming weeks’. But most of those mentions are ~3 months old.

Any update on this? ETA? Or is this feature just not coming?

Edit: I read a mention elsewhere that this was happening in ‘March’. And that rate limiting will not be tied to IP addresses…?

I have a userless application that ~50 orgs use. Under 50 IP addresses, that was fine. What is this new rate limit method going to look like? How radically do I have to change my deployment strategy?

episod · 2013-01-07T17:58:24.000Z

We’re still working on it, but most folks shouldn’t consider it some panacea that they’re waiting on – in most cases, the only way to scale usage of the API is going to be through access tokens and per-user rate limits.

Once this feature is ready we’ll announce which API methods application-only auth is allowed on as well as the rate limits allowed for these kinds of requests per method. The limits will be application-wide per window and will not subdivide per IP address or in any other way.

In the meantime, you can use a single access token and OAuth 1.0A to emulate much of this future behavior – the limits won’t likely be all that different for what can be done with application auth versus a single-user access token.

episod · 2013-01-07T17:58:40.000Z

Rate limiting in API v1.1 is per-method, the rate limits are not shared between methods.

click_tony · 2013-01-07T18:31:10.000Z

Thanks, @episod - very clear.
I may have to create a handful of dummy accounts and / or dummy applications if I can’t get all of these machines authorized. Is there a lesser of two evils or are both methods equally against the Twitter TOS?

roedvin2 · 2013-01-08T06:58:19.000Z

Hi. Will the Streaming API still allow basic authentication?

TAMUMRC · 2013-01-08T14:51:34.000Z

Any .NET API libraries available yet for v1.1 API ? We were using TweetSharp/Hammock for v1.0 but can’t find an updated version of that library for v.1.1. Thanks.

episod · 2013-01-08T15:48:07.000Z

Creating dummy accounts and applications for the sole purpose of increasing your rate limiting scenario could easily be seen as an attempt to circumvent rate limits. Having test accounts or dedicated purpose-driven accounts are often a natural part of working with the Twitter platform.

episod · 2013-01-08T15:48:37.000Z

It will at this stage, but there’s a definite future where the Streaming API will be OAuth-only as you may as well move on now.

episod · 2013-01-08T15:49:47.000Z

@joemayo has a well-liked .NET library called LINQ to Twitter that supports API 1.1: http://linqtotwitter.codeplex.com/releases/view/99764

heikofritz · 2013-01-10T15:27:20.000Z

Are you sure that the actual version of TweetSharp do not work? Tweetsharp uses the OAuth
which is required from 1.1. But i am not sure if it will work , after the 5 of March. Is there a way to test it?

aRavun · 2013-01-13T23:40:30.000Z

I feel as though REST 1.1 has made any form of Managed Application Development with Twitter insecure. Previously using REST 1.0 after tokens for a user had been generated you could omit the applications consumer key and consumer secret key using just the users key and secret. This meant you could generate the token at a secure location (protecting consumer information) while securely passing the generated user token back to your application.

Now any request to Twitter explicitly requires both the consumer key and the consumer secret meaning I’m now forced to store both on the end user’s machine. I can’t help but feel my application is now vulnerable where it previously was not.

Could it at least be possible to omit just one of the two?

euroseller · 2013-01-15T12:30:09.000Z

I encountered HTTP 410/403 error with calling user_timeline.json or update.json. Especially user_timeline.json has much more such error conditions than update.json has. If we meet such errors, how can we retry the APIs to recover without causing any rate limit error?

tenthgeek · 2013-01-16T10:25:01.000Z

Now, how do i get my favorite lists rss .
bad move by twitter

roedvin2 · 2013-01-17T13:30:47.000Z

Ok. But there will be a definitive notice about this at some point right?

episod · 2013-01-17T16:20:29.000Z

Absolutely.

episod · 2013-01-17T22:27:35.000Z

We’ve updated the [node:126] page to list only libraries we know of or have heard of as working with API v1.1. We’re certainly impressed with how many libraries and tools have already migrated!

I’m certain we’ve missed a few.

If you know of (or are the author of) any Twitter API v1.1-compatible libraries/tools (including libraries written just for HTTP 1.1 and OAuth 1.0A) and want to update us on its status, use this form: [node:14152].

Thanks everyone!

doomor · 2013-01-18T15:12:20.000Z

What about next calls which were in API v1 ?
GET statuses/retweeted_by_me
GET statuses/retweeted_to_me
GET statuses/:id/retweeted_by

Will be any alternative calls in new API v1.1 ?

episod · 2013-01-18T15:37:42.000Z

These specific API calls do not have direct equivalents in API v1.1.

You can find the tweets from GET statuses/retweeted_by_me by looking through the current user’s user timeline and isolating their retweets.

You can find the tweets from GET statuses/retweeted_to_me by looking through the current user’s home timeline and isolating the retweets.

You can find the users who performed the retweeting from GET statuses/:id/retweeted_by taking the user objects from GET statuses/:id/retweets

jnylund · 2013-01-18T16:46:45.000Z

For the last one, do new retweets on old tweets come if using since_id? Or do I need to scan the users_timeline in full every time I am looking for retweeets?