You still cannot release a twitter client that doesn't get maxed at 100,000 users. Why bother implementing ideas when it will probably meet with the same problem due to our success.
Well, the platform is not just about client apps, people use Twitter's data and features for all kinds of things. You're welcome to build on the platform if you've got a good idea.
Maybe it would be useful and clarify the landscape if the client and data/reporting API channels were separated.
Thanks for the feedback. Can you be specific about the API features that you're referring to that are "all over the place"? I'm personally really excited about this, and this is probably the most cohesive a strategy I've seen for the API platform. We're very focused on fundamentals right now.
One really obvious one: Polls. Polls were introduced in October 2015. There is still no public API to create them, view them, or vote in them -- for users using third-party clients, polls are simply invisible.
That's frustrating, I realise. It's probably the most common feature I'm asked about regularly (alongside group Direct Messages). Polls are complicated to add, as there are three aspects (creating, voting, and then seeing the results), and they depend on cards, which are also not currently part of the API. It would be good if we at least added the information that a poll is attached to a Tweet to the Tweet JSON object, even if we can't do all the other things right away. I'd suggest keeping an eye on the roadmap for where we're going, but can't promise those things right now.
Thanks for the feedback. Can you be specific about the API features that you're referring to that are "all over the place"? I'm personally really excited about this, and this is probably the most cohesive a strategy I've seen for the API platform. We're very focused on fundamentals right now.
Andy - do you have any more information on this: "A plan to replace the public statuses/filter, statuses/sample, and search/tweets endpoints with a streamlined API that provides increased access when rate limits are reached." Some kind of pay-as-you-play model? Appreciate any help - building a product to help smaller businesses leverage the power of Twitter and would like to see how, in return, can help Twitter.
Nothing specific to announce at the moment, but yes, that's the direction that we refer to in the blog post - a new developer portal that would enable you to scale via tiered pricing in the future (but that remains free to use for standard access).
It would be a good thing if, with this announcement, Twitter made a commitment for how this would have a support for the future. Like "this will be available for x months/years, you can make x requests per minute/hour/day, you can buy a plan offering x for $x dollars" and so on. Yes, that can limit some better offer in the future? Perhaps. But that make things more stable, and people would commit more to twitter. Can…
That's a really good piece of feedback that I'll be sure to pass along. In terms of plans and pricing, we're not yet announcing those details, but stay tuned as the new APIs we reference in the two blog posts today mature. We'll continue to offer free access to the APIs as well.
Twitter also did something that I find particularly interesting: they somehow convinced developers that you needed them to bless your app and provide APIs to build a client that accesses their service, even though those credentials must be distributed to the public with your client . To people like me who are old enough to have dealt with AOL, the idea that developers are willing to buy into this fiction is absolutel…
> As far as I can tell the only thing that enforces this is what should amount to an antitrust level of collusion between the mega-companies to restrict access to products (via services such as the Apple App Store) that do things that the other mega-companies dislike Actually, at least in the US you could be having legal problems... you're circumventing access controls, which may or may not be a "hacking crime". Also…
Where would someone even see these terms of service unless they have already bought into the fiction? The terms of service on usage of the official Twitter client could apply (saying you can't reverse engineer it), but if you are reverse engineering something for straightforward interoperability there is a lot of precedent, including for extremely similar services (such as the AOL Instant Messenger Client); I think they would be hard pressed to do anything more than ban you, just you personally, from Twitter.
Bummer that it's all webhooks. They're pretty fragile. It'd be much nicer if Twitter had some kind of streaming API that you could connect to with a sequence number and get any messages that you might have missed, or at least any that they still have.
We're deprecating a legacy OpenID connect implementation and rebuilding the entire user onboarding experience. Part of this requires rebuilding the authentication layer. This is the first time I used their APIs. Instead of sticking with the heard, twitter decided to stick to their OAuth1 implementation instead of adopting the standard today - OpenID. What's worse is that they've come with the ingenious OAuth Echo, which requires you to ship your mobile applications credentials embedded in the code, virtually public to anyone who decides to poke around.
Andy - do you have any more information on this: "A plan to replace the public statuses/filter, statuses/sample, and search/tweets endpoints with a streamlined API that provides increased access when rate limits are reached." Some kind of pay-as-you-play model? Appreciate any help - building a product to help smaller businesses leverage the power of Twitter and would like to see how, in return, can help Twitter.
Nothing specific to announce at the moment, but yes, that's the direction that we refer to in the blog post - a new developer portal that would enable you to scale via tiered pricing in the future (but that remains free to use for standard access).
do the current rate limits constitute standard access?
It would be a good thing if, with this announcement, Twitter made a commitment for how this would have a support for the future. Like "this will be available for x months/years, you can make x requests per minute/hour/day, you can buy a plan offering x for $x dollars" and so on. Yes, that can limit some better offer in the future? Perhaps. But that make things more stable, and people would commit more to twitter. Can…
That's a really good piece of feedback that I'll be sure to pass along. In terms of plans and pricing, we're not yet announcing those details, but stay tuned as the new APIs we reference in the two blog posts today mature. We'll continue to offer free access to the APIs as well.
Will the free Search API have lower rate limits than they are currently?
> As far as I can tell the only thing that enforces this is what should amount to an antitrust level of collusion between the mega-companies to restrict access to products (via services such as the Apple App Store) that do things that the other mega-companies dislike Actually, at least in the US you could be having legal problems... you're circumventing access controls, which may or may not be a "hacking crime". Also…
Where would someone even see these terms of service unless they have already bought into the fiction? The terms of service on usage of the official Twitter client could apply (saying you can't reverse engineer it), but if you are reverse engineering something for straightforward interoperability there is a lot of precedent, including for extremely similar services (such as the AOL Instant Messenger Client); I think t…
It's the US government I'd be afraid of. Other governments even extradite people like Kim Schmitz into the US, who never even set foot into the US, for copyright infringement. Their justification is "he had used US servers".
Who says that this cannot be done with a 3rd party client developer? The precedent is there, circumstances may be seen similar, all it needs is a clueless DA and judge and boom you have a load of problems on your head.