There's been some recent announcements (here) about changes to the Twitter API and I thought I'd take this occasion to blog, in one place, the various thoughts I've had about what Twitter should do with their API:
Distinguish between Client Apps and Third Party Apps
Make a distinction between "client apps" and "third party apps" in the REST API so that the access rate caps can be treated differently. "Client Apps" are apps that run in the domain of the one user whose credentials are being used (ie a desktop app). These sort of apps generally have no good reason for hitting the API many times a second. "Third party apps"are accessing the API in an unauthenticated manner, or using the credentials of the user (ie a third party site like http://twitter.grader.com). These have a legitimate need for high volume access.
Why is this distinction important? The answer is that the relationship between the developer and Twitter, Inc is different in the two cases. In the Client App case (such as a desktop app), the developer doesn't really care about high volume access, assuming the user isn't hitting reload an astounding number of times a second. A Third Party app developer, on the other hand, is the party that cares about rate limits. By partitioning these two types of relationships, you can segregate the market of REST API users, and implement different policies for them. You want to encourage both types of developers, but you do so in different ways. The current rate accessing policies, especially after the new caps were announced, are better tuned for Client App developers - so there's really nothing that needs changing for this segment of developers. Its the Third Party App developers, where much of the value of twitter is created, that need to be treated more predictably.
Give the Opportunity for Heavy API Users to Pay
Cap the number of requests to some reasonably large number, but offer tiers of access above that cap for pay. Along with the increased caps, offer a modest for-pay support program for heavy use third party applications. (something like $20-$100 per month for each level of 10000 requests/hr) The idea here is not to punish heavy users, but rather create an incentive for Twitter to support them better.
Everyone comes out happier that way. If I'm building a business on the service infrastructure of Twitter, I want to know that I've got a relationship that matters to Twitter, my service provider. Whats a better way to build a relationship than a revenue stream! :)
Implement OAuth Already!
Implement OAuth for third party apps and require, as terms of service, that third party apps (as opposed to client apps, see below) do NOT collect username and passwords for users. OAuth is designed exactly for this scenario, and reduces greatly the exposure to illicit username and password capture.
In implementing OAuth, you'll also be requiring that applications (either third party or desktop) are explicitly identified as a party to the REST call interaction. This is a good thing! Instead of applications being anonymous parts of the infrastructure sitting beween you and the user (at least for "reads" in the API), applications can now be identified and managed (on the Twitter side). This presents new opportunities (as if you need them) for reaching out to your developer community and gives you more insite on the usage patterns that specific applications have.
Think of Yourself as Common Carrier - Don't Discriminate
While Twitter is legally far from being a "Common Carrier", act like you are, at least from the perspective of an API provider. While you support tiered levels of service from a support and volume point of view, do NOT offer that level of discrimination for functionality. The key here is that the innovation starts on the long tail - the "big end" of the curve pays for the extra level of volume and support to sustain the service, not to create special functional access only for those who can pay. The little guys using the REST API should be able to be "big guys" simply by participating in the for-pay program when its in their interest, and not as a way to get access to an exclusive club of functionality.