Twitters API changes: what you need to know
As social network deprecates traditional API, older apps and sites may find Twitter integration broken.
This week marks the
beginning of the end for Twitter’s ‘v1.0’ API, which as announced
last year will soon be deprecated. However, many developers may
find older apps and websites that are reliant on Twitter broken as
Tomorrow (5th March), the first of many “blackout tests” will be carried out, simulating the pulling of the plug on API v1. This time, unauthenticated requests will receive an ‘HTTP 410 Gone’ response from 9:00am to 10:00am PST, but more drastic blackouts are likely to follow in the run-up to the API’s permanent retirement.
It’s a good time, then, for developers working with Twitter to test their compatibility with the newer API v1.1, which Twitter is now encouraging migration to. However, some of the differences between the two have been controversial.
The biggest single change is the 100,000 user limit on traditional clients, such as Tweetbot, which Twitter are attempting to snuff out. There’s currently no mechanism for determining the number of tokens available beyond contacting the platform team – but this shouldn’t be an issue as long as you’re not trying to replicate TweetDeck or Twitter’s mobile app.
More relevant to all developers is the compulsory use of OAuth when accessing all API endpoints. Currently, all applications require an access code from both the application and the user, although an application-only version is promised sometime in the future.
Twitter claim this change is designed to “prevent abusive behavior” and “help us to further understand how categories of applications are using the API”, though cynics might argue it’s more about preventing applications they don’t like (such as weknowwhatyouredoing.com).
On a positive note, most applications should be able to query the API more often due to changes to rate limiting.
API v1.1 also introduces new developer display requirements which outline a standardised layout for tweets – essentially insisting that all tweets look exactly as they do on their website and apps.
How will Twitter enforce this policy? Well, for one thing, traditional XML, Atom, and RSS feeds will be deprecated along with API v1.0, nixing hundreds of custom timelines around the web. This also means that old versions of the official old widgets, which relied on these feeds, will stop working (Twitter now recommends new widgets tied to individual IDs and specific domains).
Some may disagree with these changes, but as it’s Twitter’s API, they can do what they like with it. Those looking for more freedom might want to look at the considerably more open (albeit smaller and pricier) App.net.