Discussing API v1.1

dtran320 · 2013-02-27T00:13:00.000Z

Hey Rob,

You probably already founded Embedded Timelines or came up with another workaround, but in case you haven’t, this sounds like the perfect use case for it: https://dev.twitter.com/docs/embedded-timelines

mgokhanbakal · 2013-02-27T02:05:29.000Z

It seems that nobody knows something about my previous post. That is interesting, huh?

jnylund · 2013-02-27T15:27:50.000Z

Is there any timeframe that you will get back to us on this? 1.1 deadline is rapidly approaching and havent heard a word…

JustinZollars · 2013-02-27T16:23:00.000Z

Will this API call, which returns a user image become deprecated or require authentication in v1.1?

http://api.twitter.com/1/users/profile_image/justinzollars

Also I want to voice in, as a longtime twitter api user, who found it a joy to develop on your platform, I am pretty unhappy about the changes to a less open direction. This is a move in the wrong direction.

dtran320 · 2013-02-27T17:10:56.000Z

Hey M. Gökhan,

You are correct, statuses/retweets/:id has a limit of 100 retweets. In v1.0, it was previously possible to get up to 800 retweets using statuses/:id/retweeted_by, but that endpoint has been removed in v1.1. Regardless, it has always been the case that you need to use the streaming API to get a full list of retweets.

For your latter question, you could walk their user_timeline and look at the retweet_count parameter of each tweet.

mgokhanbakal · 2013-02-27T21:53:12.000Z

Thank you @dtran320 for your reply. Do you have a link of streaming API for getting retweets method?

Thanks.

episod · 2013-02-28T15:15:29.000Z

Yes, /1/users/profile_image will cease allowing access, whether authenticated or not. It’s not part of API v1.1. It was a method often used counter to its intention (many used it as the SRC attribute for an IMG tag) and the same information is available in [node:10320], while keeping [node:10796] in mind.

HamFon · 2013-02-28T18:09:45.000Z

In migrating to v1.1, I have a couple of questions relating to authenticating (and permanent authentication until revoked) in a userless application-only context.

I have a web-based application that, when a user updates their list of stuff, tweets this new information for people who are following them. It (currently) does not need to be reauthenticated each time they change their list, and as long as they sign in to my application, I have the Twitter authcode info to tweet without requiring them to OK the permissions for the app again.

Can you outline a simple method for the user to provide tweet-posting permissions for my app with V1.1? Specifically, I want the user to be able to select my app one time, provide the appropriate permission selection, and then have my application be able to tweet on their behalf in the future (including future sessions, etc.).

Also, when I first set this up, I was using OAuth.php and twitter.class.php from about a year ago - and I’d like to either update those or provide external php links to these that are always up-to-date. Should I still be using these, or update to new procedures?

So in summary I want to update to V1.1 for my userless server-side php app to do this:

Twitter user selects my app one time, and gives permissions for my app to update status on their behalf
All future access to my app continues to allow status updating from my app - until revoked by the user
I would like to simplify the original user authentication as much as possible - to let the user give my app permissions, but to do it simply and streamlined.

Thanks.

Nelson

matteosisti7 · 2013-02-28T20:41:00.000Z

https://dev.twitter.com/docs/tweet-entities
Here it says:
“With the REST API, you’ll need to set the include_entities parameter to 1 (or true) if you want entities to be included.”

However here: https://dev.twitter.com/docs/api/1.1/post/statuses/update
there’s no mention of the “include_entities” parameter.

Am I missing something or is the documentation out of date?

dubiousbaldwin · 2013-03-01T00:16:56.000Z

@episod we’re having the same concerns for numerous previously public API v1.1 endpoints (such as your example, user timeline) that still show “user context” as being required. With the v1.1 deadline fast approaching, it’s extremely concerning that this documentation has yet to be updated with what months ago was described as an improvement that could be expected in a few weeks.

Thanks!

episod · 2013-03-01T15:24:24.000Z

Yes, in API v1 entities were opt-in. In API v1.1 entities are opt-out. Once we live in a purely API v1.1 world, you’ll find many of these docs that speak to both worlds or only the old world better reflecting the new present.

AymanFMustafa · 2013-03-01T22:22:16.000Z

The docs state that the rate limits apply per app, so each app should have its respective limits (excluding those limits that apply per user, of course). However, it looks that for apps using the iOS Twitter framework, the rate limits are shared by all these apps. Is this a bug, or is the whole iOS framework considered one app?

brightchimp · 2013-03-02T10:46:08.000Z

I access the API via the ruby gem.
I have 2 versions of our app running, one on the old API (gem v3.7.0) and one on the new API (gem v4.5.0).

Yesterday I started sending tweets using the new API.

I successfully sent tweets from several accounts but had one fail to post a tweet several times (we re-try after a minute on certain types of failure). I had successfully sent tweets from that account earlier, using the new API.

The gem defined error is Twitter::Error::Unauthorized, with the message ‘Could not authenticate you’.

Switching back to the old API sent the tweet at the first attempt.

It seems random and I can’t test on our production env with the customer account that had the problem. I have had no issues using a test Twitter account sent the tweet.

Thanks for any guidance.

brightchimp · 2013-03-02T12:08:52.000Z

I have managed to reproduce. It looks like the problem is that the tweet I am trying to send contains the \302\240 character. This wasn’t an issue with API v1, where do you see the line of responsibility for sanitizing tweet text?

Cheers
Peter

ikarienator · 2013-03-04T05:37:35.000Z

+1 The rate for social graph APIs is unacceptably low. To get the follower ids of 1 user with 1M followers, will take 3 and a half hours. By the time the data might be already out dated.

To build up a social graph will need ids from tens of thousand people. It is acceptable to be done in 3 days, not 1 month.

I’m totally fine if you charge money for API calls, at least I can access them from one way or another.

pacunar · 2013-03-04T15:31:40.000Z

Starting from last thursday (February 28th) I am not receiving the retweeted_status object using the Search API v.1.1. Does anyone else have this problem? I’ve been using the search API for some time now and I didn’t have the problem until now. I’m using the latest version of twitter4j.
Thanks!

tapbot_paul · 2013-03-05T13:22:43.000Z

Users seem to edit lists in batches, either creating a list and adding a bunch of users to it or going through their followings and adding users to different lists. The way to manage memberships in our app involves selecting a user and choosing the “Manage List Memberships” option. This queries the GET lists/memberships method and gives the authenticating user the option to add/remove the target user to/from multiple lists at once. When doing these, infrequent, “mass” edits they are running into the rate limit for GET lists/memberships.

As with most List related API calls, this one isn’t used by most people but the ones who use it are highly impacted by it. I’d appreciate looking into this as a rate limit increase candidate.

Thanks!

matthauger · 2013-03-05T13:29:24.000Z

Has the “userless” scenario been implemented/documented? Maybe I missed it?

amarpreetkalkat · 2013-03-05T17:34:00.000Z

We have been seeing a similar problem with the v1 Search API since Thursday too. I did file an issue (https://dev.twitter.com/issues/896) but have not seen a response yet. At least one more issue is filed for the same problem (/895).

I hope @episod can provide some clarity if this is a temporary issue or something else.

episod · 2013-03-06T15:03:53.000Z

We resolved this issue yesterday. Thanks for reporting!