In mid-August, Twitter announced there would be big changes coming in v1.1 of their API which they then released at the beginning of September (officially deprecating the v1.0 of their API). Well, three days ago my Twitter Statuses JavaScript Badge stopped working on all my sites and everyone else’s that uses it too.

Back when I first started its development in 2007, there was no official, versioned API and it’s managed to continue working this entire time. Clearly, Twitter decided that with v1.0 of the API deprecated, that anything using older calls than that would no longer need to be supported. So, I’ve updated to the v1.0 API calls and all is working again… for now (more on that in a sec).

Go download v0.7.2 now (the source code is also on GitHub), or you can just change the following line in your HTML:

<script type="text/javascript" src="http://www.twitter.com/statuses/user_timeline/morgant.json?skip_user=true&callback=makkintosshu.twitterStatuses.twitterCallback"></script>

To the following (replacing “morgant” with the appropriate Twitter username for your use, of course):

<script type="text/javascript" src="http://api.twitter.com/1/statuses/user_timeline.json?screen_name=morgant&callback=makkintosshu.twitterStatuses.twitterCallback"></script>

A Few Words on the Future

Now, v0.7.2 of my Twitter Statuses JavaScript Badge only brings us up to v1.0 of the Twitter API which is now deprecated and will be discontinued in roughly six months. Why not go straight to v1.1 of the Twitter API? Well, there are two major changes in v1.1 that would have a major impact on the JavaScript badge: requiring OAuth for all API requests and the display guidelines will become display requirements.

The latter, requiring the JavaScript badge’s display to conform to the specific display requirements, would require some minor CSS changes and is not too big a deal. That said, since the primary goal of the JavaScript badge is to allow customization of the styling, esp. integrating with a site’s theme, it could not enforce that only certain styling rules would be modifiable and so it’d be up to the developer using it to ensure that they too were meeting the requirements. This might be acceptable, but there’s also a chance that Twitter would object.

The former, requiring OAuth authentication for all API requests, is unfortunately a show stopper. OAuth requires registering an application with Twitter (easy) and using secret access tokens as authorization to the API (the problem). The reason this is a problem is that JavaScript runs client-side and can be fully inspected by any user, so the secret access tokens are not very “secret” and could easily be reused by someone else for nefarious purposes.

The OAuth issues could be worked around by implementing the badge server-side in PHP or another language, but then it would not be the same paste-in solution it currently is. I could create a web service that acted as the middle-man, allowing one to create badges that would be populated using a small amount of JavaScript and allowed me to control the majority of the CSS styling with hooks for specific theming, but then you might as well just use the official Twitter Embedded Timelines badges.

So, the future for my Twitter Statuses JavaScript Badge looks bleak. It’s highly likely that this is its last six months, which is too bad as I still had features planned. I’m not going to call it quits yet as I’ve got a number of months to consider my options, but discontinuing it is definitely on the table.