The Twitter API continues to see incredible growth and adoption, including Wordpress and Tumblr both emulating the API, in turn providing access to their services through standard Twitter clients. It has been suggested that this adoption of the Twitter API by outside groups marks the beginning of a movement that will see it adopted as a standard for microblogging platforms.
Given the vast number of developers, products and companies that rely on their API, one challenge that the Twitter API team has had in enhancing their API is a lack of any version support. Without versioning any changes to the Twitter API could break compatibility with both existing apps as well as outside services that had adopted the interface. This meant that Twitter could either freeze their API or provide a moving target those that were emulating the interface, who would be forced to implement any new changes.
Recognizing these limitations, Twitter is taking steps to add a versioning system to their API:
We’ve taken the first steps toward introducing versioning into the Twitter REST API. With a versioned API we can make ambitious improvements *today*, not tomorrow, without worrying about breaking backwards compatibility. This will lead to both a better and more reliable API.
For now we’re keeping it simple. No subversions, no implicit version defaults, no fancy-pants etc. We’re leaving our approach open to these types of additions, but we aren’t going to support them until we feel a compelling need to.
Developers are encouraged to update their applications to support the new versioning scheme:
We also don’t have a hard date for when API requests to http://twitter.com will no longer be serviced. We aren’t planning on pulling the rug out from anyone though. Please update your applications to the new http://api.twitter.com/1 at your soonest convenience. The non API urls likely won’t be supported forever.
And as you can see in the quote above, Twitter is also moving API calls over to the domain api.twitter.com, rather than twitter.com, which again will provide more flexibility going forward. From the above thread you can see example of both the versioning and domain change:
So for example, what was
Twitter have also responded to some of the legal issues that surround the adoption of their API by outside services. A reply has been made to a forum post started by one of the Wordpress developers suggesting that they are open to more widespread adoption of their API:
What we do know is that there is a clear need for a flexible, friendly and responsible policy. Policies such as this one ( http://code.google.com/policies.html#restrictions) are a good start, and I can share some principles we’d like to live by. CC-BY should apply to a lot of the tools we release. You should be able to copy, modify and make derivatives of our specifications (with attribution). We shouldn’t throw arbitrary roadblocks in your way, such as preventing you from naming a library “tweet.” And last, we shouldn’t pester you for utilizing our patents underlying these specifications.
These are flexible and friendly principles, and in exchange we ask the development community to act responsibly. For example, naming a library “twitter” is one thing. Naming your application “twitter” is quite another.
With moves like these, Twitter will be able to advance their platform, but while still addressing the practical and legal issues of developers and those that emulate their API.