Navigating the new Twitter API
At the end of last year Twitter announced that, come March 2013, there will be some significant changes to Version 1.1 of the Twitter API. Whereas the rules on this have been pretty relaxed until now, new guidelines will require authentication on every API endpoint, a new per-endpoint rate-limiting methodology and changes to Twitter’s ‘Developer Rules of the Road,’ the latter of which focus on display guidelines and requirements. It’s a lot of information to absorb and just what the effects will be remain somewhat unclear at present. In layman’s terms however, the changes can be summed up as two-fold, with one focusing on the technical aspect, the other on how Twitter activity should be displayed.
Currently, Twitter allows developers to access API endpoints without any authentication. Essentially, this means that access to public information from the twitter API can be obtained without Twitter knowing who they are. But, from March, developers will either have to use an off-the-shelf widget with very limited design customisation and restrictions on how it can be displayed or they will need to build an authorised link between the Twitter account and where the link to the timeline is shared, if they want to apply a more bespoke design.
The process behind this is considerably more involved than the currently available methods, and depending on the platform may require expert coding ability in order to implement it.
For developers of bespoke websites, the coding process will be even trickier. This begs the question as to whether or not anyone will see it’s worth or whether it will just open the door for new ways to share social media in the future.
As well as requiring a more technical approach, the new changes will also affect display. What have been guidelines to date will soon shift to requirements. Among these will be the necessity to link @usernames to the correct Twitter profile as well as displaying ‘favourite,’ ‘reply,’ ‘re-tweet’ and any other Twitter activity depending on the device. Fail to comply and Twitter can revoke your application key. While this is great for Twitter looking to drive more traffic to its site, the faff element may once again mean that it’s abandoned altogether.
It’s also important to note that enforcing this will be extremely difficult and is only possible if Twitter manually checks. Whether or not you would run the risk is a separate issue but how Twitter plans to carry out any kind of enforcement will be interesting to see.
These are just some of the changes that developers will have to adhere to from later on this year and Twitter is of course providing a full run-down in more detail. What do you reckon the impact will be? Tweet us at @ahoystudio and let us know.