Why do I need to authenticate to grab a feed from a public twitter account?


#1

Can someone enlighten me on this - maybe I’m confused, but I used to be able to parse an XML or JSON feed of a public twitter account simply by sending a request to:

http://twitter.com/statuses/user_timeline/USER_ID.rss

I would read that feed, save it in a cache on my server, then show those tweets. I’d recreate the cache a few times a day just to reduce the calls I was making to twitter.

Now it seems I need to use oAuth to do the same thing:
https://dev.twitter.com/docs/api/1/get/statuses/user_timeline

  • Does this mean I have to create a new application for every separate website that is going to use this type of request?
  • Does this mean each user whose feed I’m parsing needs to authenticate that application?

Any insight would be appreciated.


#2

Requiring that your application identify itself when requesting our servers to retrieve and serve a user timeline doesn’t make that timeline any less public than it was when you were able to make a request without such identification.

The Twitter API has served content in a variety of formats, including XML, JSON, RSS, and ATOM. Back when the API was first created, future-proofing wasn’t such a concern and thus “unversioned” endpoints like twitter.com/statuses/user_timeline.rss came into being. A number of years ago, we corrected the mistake of an unversioned API and asked everyone to move to the api subdomain and the version 1 path…

Now a few years later, we’ve retired the old unversioned endpoints we warned folks to move away from and have a properly versioned API. Version 1 of the API still supported RSS feeds, ATOM feeds, and making unauthenticated requests. Version 1.1 supports only JSON and requires authentication.

On to your questions:
Does this mean I have to create a new application for every separate website that is going to use this type of request?

  • Not necessarily. But a website is a kind of application in these contexts. We’d prefer you use our Embedded Timelines to render tweets in these contexts. Otherwise, you’re responsible for meeting our display requirements yourself. Whether a different application is required for each site is really up to you and how you want to model your relationship with the API. You may potentially consider your consultancy as the application. The vernacular is kind of fluid.

Does this mean each user whose feed I’m parsing needs to authenticate that application?

  • Also not necessarily. It depends on how you look at the problem and what your goals are and how you’re thinking about rate limiting. Your own access token can be a stand-in for actual end-user authentication, but then you only have one access token’s worth of requests to make. One access token can requests multiple users user timelines though. In the future, we’ll have a form of authentication that allows your applications to make requests on its own behalf without a user context.

Hope this helps to answer your questions.


#3

The embedded twitter feed widget notwithstanding, is there a specific reason for needing to be authenticated to access what is effectively public information through the API?

As we are a design firm, a cohesive visual style is very important to us, and many of our clients too. These changes are going to cause us to use a lot of extra dev time, so I’m interested to know the reasoning behind this system design decision.


#4

From what I’ve gathered, the changes would tell me that the new authentication is to effectively reduce the amount of calls on the twitter servers (bandwidth) and to reduce abuse. They only want registered twitter accounts reading from registered twitter accounts. I also imagine its so they can be sure they are making money (through advertising) of said registered accounts as all the calls will be tracked.

Whilst I completely understand the need for those changes, its quite problematic for clients and their websites.
Like you, I work in a design agency and build sites. I just cannot see how our clients are going to want to use the default embeddable widget that rubs against the design of their site. Neither can I see them start fiddling around with the API App settings from within their twitter account to provide us with the necessary code to fix their custom feeds. I just dont think it would be cost effective to firstly ‘consult’ with the client then ‘fix’ through dev time for something rather trivial.

I imagine native blogging software (wordpress and the like) and G+ will be getting some extra attention at the moment.

I think this could be the turning point for twitter and it sort of goes against what made it so special in the first place, time will tell.


#5

G+ it is.