Discussing API v1.1

janole · 2012-09-10T08:32:58.000Z

Will the undocumented call related_results/show be added to the API 1.1 or will it be killed for third-party devs?

This is a pretty useful call for fetching conversational threads …

richardhyland · 2012-09-10T10:51:06.000Z

I noticed this wasn’t ported across either, it was a versioned API even though not documented.

Twitter.com still uses it but they are still using the version 1 API so we can’t see if it changes or if we’d be allowed to access it either.

episod · 2012-09-10T16:57:37.000Z

[node:9708, title=“POST statuses/update_with_media”] is now fully functional in API v1.1. As an added bonus, you should no longer use upload.twitter.com as the host when interacting with this method. Use api.twitter.com instead, just like the rest of the REST API.
Some have expressed concerns about methods not present in v1.1 without functional equivalents. I’m collecting these concerns and will relay them to the appropriate teams. A few of these are instances where the methods were not ready for 1.1 at time of release.
Thanks to everyone who has helped identify documentation or implementation bugs in 1.1; we’re continuing to improve documentation throughout the site; especially in areas where confusion has arisen.
You may not have noticed that the Streaming API is now also available at 1.1 version endpoints. Please switch over to these as you’re updating your applications.
The new Search API’s response structure still makes reference to paging concepts it no longer services. We’re working to rectify this and I’ll update this thread when the documentation is updated to reflect its final structure.
[node:64] will have no functional equivalent in version 1.1. The user object is the most correct place to retrieve a user’s current avatar as well as the rest of the information that comprises their Twitter identity. See [node:10796] for more information on avatar variations.

Keep the feedback coming, thanks.

episod · 2012-09-10T17:00:22.000Z

The undocumented/unsupported related_results/show method will not be making an appearance in API v1.1 at this time.

episod · 2012-09-10T17:03:34.000Z

API v1.0 will cease functioning in approximately six months from v1.1’s announcement – March 2013. v1.1 is operational now. You will likely need to rethink how you approach limits and the offerings available to you, including the Streaming API, to migrate your application to the v1.1 world. Search whitelisting will not be grandfathered/transferred to v1.1 and we recommend you to leverage authentication and the per-user rate limiting model along with the Streaming API.

SoreThumb · 2012-09-10T17:23:47.000Z

Why is there no API call to grab a user’s tweets & retweets without requiring an OAUTH/User Context, if the requested user has a public account? I saw statuses/user_timeline.json, and it requires a user context.

RSS feeds performed this function already. You’ve said that the RSS feeds are going away. So, I won’t be able to do this anymore, and the only replacement is the API call that returns JSON.

I looked at and saw that it requires user context. But wait, isn’t this a downgrade of accessibility? And will the Application context be provided soon enough so that I can get some minor consolation, versus requiring to OAuth my own single-user apps?

episod · 2012-09-10T17:34:30.000Z

As mentioned above, we are working on a variation of authentication for API v1.1 that will allow for an application-only context not requiring a user context. When that feature is made available, methods not requiring a user context will have their documentation updated to indicate as such (until then, all methods require it). If access-without-a-user-context is important to you, you may want to wait to implement 1.1 until those features are available.

SoreThumb · 2012-09-10T19:11:25.000Z

Will old features (EG: RSS) that have access-without-a-user-context be postponed removal until a time after Application-only context’s implementation?

twitlistmanager · 2012-09-11T08:09:56.000Z

When looking at the changes in 1.1, specifically the rate limits, I found that almost every time I thought that this change would surely make my app unusable, it wasn’t as bad as it seemed. The larger rate limits for some methods (for instance GET users/lookup) are perfect. Except for one.

My app is a list manager app, and I’m very excited that I’m now getting 4.000 unique visitors a month. I see people making comments like “why doesn’t Twitter just have this” which is the biggest compliment I could get. With the new version (new functionality, better UI), I hope that growth will increase. But specifically the rate limit on GET lists/members seems so strange. I don’t know what the average number of lists per user (that has lists) is, but let’s say it’s 3. With the new rate limit I could service a maximum of 5 users every 15 minutes, that’s 20 per hour. I’m reaching 21 per hour already, on a good day. That means I will run into problems, even with a relatively low number of users.

I don’t know if you’re still considering any changes at the moment, but if so, with this use case perhaps a change in the rate limit of GET lists/members could be considered?

Also, you mention that the rate limiting being proportionate to the number of lists a given user were subscribed to or owned is not going to happen, which I can understand. I really like @FlockOfBirds’ idea, whitelisting per endpoint. Do you have any further information on the formal avenues to request elevated access?

grepable · 2012-09-11T18:07:56.000Z

@sferik +1 for that spreadsheet, it’s handy.

UniofAdelaide · 2012-09-12T02:22:54.000Z

Last year we wrote a server-side script that caches our twitter feed so that we don’t have embarrassing breakage on our site when twitter is down, or suffer protracted load times when twitter is slow. It doesn’t comply with the new display guidelines but we can do that work. However my reading of the new TOS leads me to think that the caching behaviour of this script will not be allowed in future.

It seems a pity that we can’t protect ourselves from being overly reliant on twitter’s uptime - which we have little faith in. Is this in fact the case?

jerrylthompson · 2012-09-12T03:30:29.000Z

How does oAuth Echo work in relation to 1.1? I don’t believe I see it being discussed yet. As a photo sharing site, we use oAuth Echo in our API endpoints. Is oAuth Echo available in the 1.1 specs and currently working?

A 3rd party app tried to use:
https://api.twitter.com/1.1/account/verify_credentials.json

and apparently it failed.

What’s the status of this and what should we the delegator be aware of? Is it simply a matter of changing the x_auth_service_provider from https://api.twitter.com/1/account/verify_credentials.json to use https://api.twitter.com/1.1/account/verify_credentials.json instead?

episod · 2012-09-12T14:20:11.000Z

OAuth Echo should be performed the same on v1.1 with the URL you’ve shared. Some media service providers may not yet recognize that as a valid x_auth_service_provider if they chose to hardcode the allowable URL in their implementation. API v1.1’s OAuth layer is also a bit stricter than v1’s. Overall, from the perspective of the Twitter API itself, OAuth Echo requests to account/verify_credentials are no different than any other valid, signed request to account/verify_credentials.

rgeraldporter · 2012-09-16T03:28:19.000Z

Hi folks,

I’m a little concerned about v1.1 and the impact it will have on our company’s use of Twitter. We currently have about 12,500 mobile apps (web based using javascript touch frameworks) and are growing about a 1,500-2,000 per month right now. These apps are for small businesses, arts and non-profits, and lots of others who want a twitter feed in their app. These apps are basically auto-generated based on data like the name of a twitter account, feed from a blog, facebook page, contact info, etc.

In v1.0 we have no trouble delivering on that, as the feeds we are showing are unauthenticated public data (a user’s feed and/or branded or industry hashtags) and limits being based on IP meant we never hit rate limits (except inside our office sometimes!). Now that we need to authenticate and there’s a stricter rate limit, how are we supposed to manage to keep thousands of apps down to a very small number of requests realistically? I doubt its realistic for us to sign up for thousands of application keys, especially when all we’re trying to do per-app is usually get one user’s tweets into their own mobile web app, what should be very easy.

What should our approach be in v1.1? We don’t do end-user logins, while we might add that ability some time in the future we’ll never be using it as a full twitter client (more of a curated single topic/hashtag-based client if anything). After reading through the restrictions of v1.1 I can’t see an obvious way in which we can easily continue to support Twitter as our recommended platform for getting status messages into our customer’s apps. Any insight you can provide here would be hugely appreciated.

codedeluxe · 2012-09-18T20:16:42.000Z

You should put the width option on the widget page where it would be helpful

shift8creative · 2012-09-18T05:49:25.000Z

In your search results using the /1.1/search/tweets.json endpoint, you have a “geo” field and a “coordinates” field both with “coordinates” underneath which is fine but one has lat, lon and the other has lon, lat. “geo” is correct and “coordinates” is the one reversed…Though I’m also not sure why there’s two fields and which one I should be using. Edit-- I read about the GeoJSON thing…So now I know why they were flipped. Well, the “standard” is bad. Sorry to say…Because you can’t take the coordinates and plot them on a map as is.

JoeMayo · 2012-09-19T23:09:45.000Z

Are the X-FeatureRateLimit… headers deprecated too?

BTW, I did find the new X-Rate-Limit… headers.

Joe

episod · 2012-09-20T15:01:55.000Z

You’ll still see X-MediaRateLimit-* headers when using statuses/update_with_media (at least for now), but otherwise you will not be seeing X-FeatureRateLimit-* headers as every “feature” (or endpoint) is now rate limited independently from each other and the “feature rate limit” is no longer necessary.

luigilobello · 2012-09-20T16:53:00.000Z

I need to use search API in a “userless context”.
In order to migrate my apps to API 1.1 I’m waiting for application-based authentication where each app will correspond to a specific Twitter app.
I’ve read this FAQ:
https://dev.twitter.com/docs/faq#10659
Is there any news about the release of application-based authentication?
Is there any temporary workaround that I can implement waiting for this release?

JoeMayo · 2012-09-20T17:42:19.000Z

X-MediaRateLimit - I missed that one - thanks.