Twitter API v1.1: What Does it Mean For Developers?
Earlier this month, Twitter released v1.1 of its public API, the first upgrade to the API since launch. The initial version still works, and all developers and consumers of the API have six months to migrate to the new API before the 1.0 version is sunset on March 5, 2013. We’ve tried to look at those changes and evaluate what it means for the developers and apps.
As v1.0 will be deprecated, quite a few endpoints will be either renamed or replaced, and a few will be completely removed. Here is a list of endpoints changed from v1.0 to v1.1, with links to the respective API pages:
Most of these transitions just involve a minor change in the url used to call the endpoints, and this is when well-written, efficient code will win. However, the following APIs will cease to work in v1.1, meaning you will no longer be able to find out retweet-info and daily/weekly trends through other APIs:
OAuth mandatory for each call
Most apps will have to be changed to adjust for the above new URLs but a bigger change would be required to adhere to the new authentication policy: v1.1 now requires authentication with OAuth 1.0 for each endpoint, as opposed to one authorization for all endpoints in the existing version. [Why not OAuth 2.0, as everyone else does?]. Also, while version 1 returned an HTTP error code 401 (Unauthorized) in the absence of a valid authorization code, v1.1 returns a 400 (Bad Request):
Token and rate limits
A token is generated when you ‘Grant Access’ to an app, and can be used to authenticate a user until access is manually revoked, when the token returns to the pool. Twitter is capping the number of tokens an app can have to the higher of 100,000 or twice the existing number of tokens on the date of announcement of the change. Once the limit reaches, the third-party developer has to contact Twitter and request for additional access, or begin to work with Twitter directly, by becoming a Twitter Certified Product, or otherwise.
Though the token limit applies only to the clients replicating the Twitter experience, this would definitely reduce competition for Twitter’s very own client Tweetdeck, whose market share fell from 45.70% in 2009 to 13.4% in 2011. The limit is already posing challenges for Tweetbot developers.
The existing rate limit, the number of GET-based requests per hour per access token has also been modified, and is most likely the only positive thing out of this API change. While version one allowed 350 requests in a block of 60 minutes, v1.1 has blocks of 15 minutes each, allowing 15 or 180 calls per endpoint (per method), based on the type of call, tweets and search listing providing the higher rate.
XML, RSS, Atom no longer valid formats
API v1.1 will supported only JSON as the format. While XML support was dropped from Streaming APIs in December 2010 and from the trends API in September 2011, Twitter will now discontinue supporting XML, and RSS and Atom from March 2013. This is one area where users–and not only developers–will be directly affected: users will no longer be able to subscribe to RSS/Atom in their favourite feed reader, and a client cannot post Twitter content to another service. While services like IFTTT recipes would be spared of the 100K limit, they may be rendered useless for Twitter because of this limitation.
Embedded Tweets and Timelines
Individual tweets and user and hashtag-based timelines can now be embedded within other pages; in fact, that is the only permissible way of reproducing tweets as per the new Developer Display Requirements, effective from October 5, 2012. Embedding Twitter timelinesis a good idea, since you can now interact with it in the same way you do on twitter.com: expand tweets to see photos, media, start a conversation, follow users that you discover, and reply to, retweet, or favorite tweets directly from the page.
Implications and reactions
While a mandatory OAuth may stop abusive behaviour, it also gives Twiiter the power to control and monitor the use and users of data. Limits and strict display rules will affect Twitter clients, mobile apps, Twitter plugins and widgets, enterprise social media management tools, search engines, content publishing sites, and many other third-party uses of Twitter.
Basically, Twitter no longer wants third-party developers to focus on consumer facing apps. Another thing developers would be afraid of is that the policy can change at any given time, potentially invalidating their app, or requiring massive rewrites of certain parts.
The new Twitter API rules were obviously unwelcome in the developer community. Bottlenose.com CEO Nova started a Change.org petition to urge Twitter to keep its developer API ecosystem open, and there are reports of Occupy Twitter movements. If Twitter is serious about these new rules, lots of popular, mainstream services could be affected, the actual impact of which will can only be seen post March 5, 2013.
What are your views? Are you affected by these changes? Do you have extra workload now for your startup before the v1.0 API deprecation deadline?