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.
