As a corollary, I thought it naive that the author thought that there shouldn't be some kind of rate limiting in the UI.
If there wasn't, one could reverse engineer the API calls that the UI makes, in order to gain access to un-limited calls.
A good lesson for developers - even though you may have a developer API, you should still consider your public interface as an API, because it can (and will) be reverse engineered.
Even better - use exactly the same, publicly accessible APIs in your front-end!
Some good points made here, but I think the gloom and doom is a little overstated.
Facebook went through the same thing for awhile and then created facebook lite, then rolled more simplicity back into their main app.
A company like twitter is going to have a hard time pleasing everybody, and has to figure out the boundaries with its APIs as time goes on. In UI rate limits? They are probably battling spammers gaming the regular frontend like crazy, and are still hammering out the kinks for the real users.
As far as Dick Costollo goes, if there is anyone who I think would be pretty adept about balancing core ideals, while actually making money, he seems like the guy.
#newtwitter is now an API client. Like any other client, we are subject to rate-limits. The fact that the JavaScript API upon which #newtwitter is built can make authenticated, fully client-side API calls, rate limits are necessary.
Yea, but users could give a crap about that. It's their official product and the default way for people to use the service. It shouldn't have rate limits on how much you can use their website. They need to fix it.
This is the intention, but there are probably some limits that we could afford to refine. As people switch over, we're starting to get some good data around usage patterns and will certainly tweak if necessary.
Sounds like someone's a little bitter about an API usage dispute and a poached employee.
He brings up legitimate, but minor issues that are just a part of Twitter's growing pains. Let's be honest, the background customization has never been a huge selling point for Twitter. Sure its fun, but most people use Twitter via mobile clients & txt messaging and never see the backgrounds. I think I've seen the backgrounds of maybe 10 of the people I follow.
The #newtwitter rate limiting is an annoying issue they need to resolve, but they'll resolve it. They're still ironing out the #newtwitter kinks.
As a co-founder of Poll Everywhere, you might do your homework first before publicly humiliating yourself demonstrating a lack of basic background research and fact-checking. Poll Everywhere is in no way a spam operation whatsoever.
It seems to me that, as Twitter goes the monetization route, these kind of changes only make more sense. They could have taken the option to charge developers for accessing their API's. But that would slow innovation.
So, it was only natural that they would look to create a larger piece of the pie for themselves while also trying to make it possible for developers to continue to be successful. Yes, that means that we, the developers, are now being forced to compete with them which seems like a non-starter. However, they are still providing an API for us to use which allows us to continue to compete.
In the end, dare I say it, they become Microsoftian in their API evolution; they use the API without releasing it to us and develop such a headstart that it is impossible for us to compete when the API is made public. If that happens, oh well. It was free and fun while it lasted.
If there wasn't, one could reverse engineer the API calls that the UI makes, in order to gain access to un-limited calls.
A good lesson for developers - even though you may have a developer API, you should still consider your public interface as an API, because it can (and will) be reverse engineered.
Even better - use exactly the same, publicly accessible APIs in your front-end!