The death of the Twitter API or a new beginning?

REST in peace

By  

If you asked me what Twitter’s greatest strength was, I would say it was its ubiquity. Anyone could integrate Twitter into practically anything with minimal effort. With the upcoming retirement of the Twitter API v1 in March 2013, that ubiquity may be gone.

About a year ago I posted an article about how easy it was to display a twitter timeline using jQuery, along with a sample project of the code in action. The code is simple and makes use of the extremely accessible Twitter API v1. In fact, it’s so easy that you can just enter a link into your web browser and get the data you’re looking for. Go ahead and try it*: https://api.twitter.com/1/statuses/user_timeline/Mombrea.json?callback=?...

*This will stop working when API v1 is shut down

The Problem

Part of Twitter’s success is owed to this uncomplicated web API. With the looming migration to API v1.1 that simplicity will be lost at the hands of OAuth. Don’t get me wrong, I don’t think there is anything bad about OAuth, but Twitter will now be requiring any and all access to the v1.1 API to be authenticated via OAuth. This means that performing the basic act of reading a public timeline will first require an application to be created with Twitter, that application being configured with your secret client key, and the application completing the OAuth handshake before using the API.

What this also means is that Twitter applications will be limited to server side code in API v1.1. I’ve had several requests for an updated post explaining how this same task can be accomplished in API v1.1, and the answer is, it can’t be. While there are OAuth libraries available for JavaScript, the client side nature of the language means that your OAuth Secret Key will be exposed, a major security flaw that can’t be allowed.

Reducing the API to server side code isn’t a giant issue on its own, but requiring every application, every wordpress plugin, every mobile app that uses Twitter to register with Twitter’s developer program and to authenticate on every website/device is.

Reasons for the move

I have some theories on why they are moving in this direction, three of them actually.

1) Twitter has had availability issues (read fail whale) since its inception. It was way worse 18 months ago than it is today, but they still have their problems now and again. The liberal nature of their API v1 has most certainly lead to it being abused causing significant load on their servers.

By restricting the access to API v1.1 to only authenticated and registered applications, they can strictly enforce their rate limiting policies and ultimately reduce the load on their systems.

2) Instead of giving you easy access to timelines for your own code, Twitter has made available a series of Embedded Timelines. They make it easy to paste a code snippet into your site and have a timeline appear which is not subject to rate limitations, but your control over that feed is restricted. If I had to guess, I would say that this is a play toward extending the reach of their sponsored tweets (aka advertisements) via these embedded widgets that they have more control over.

3) With many security problems plaguing the platform such as follower buying services, twitter spam, and embarrassing account hacks, this could be a drastic step toward reducing the vulnerability of the service.

Fail or Fly?

So will this change result in a fallout? It’s hard to say but my money is on a sharp decline in 3rd party development for Twitter. On the flip side, it may usher in a new era of quality integration, platform reliability, and potentially greater user satisfaction based off of that. It may also bring even greater profitability to Twitter, and in my opinion they deserve it more than almost anyone for changing the way the world communicates.

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Unified CommunicationsWhite Papers & Webcasts

See more White Papers | Webcasts

Answers - Powered by ITworld

Ask a Question
randomness