Well remember with Search you don't need to proxy from your server -
instead the Search API supports JSONP so you can run it directly from
the website.

Regarding Toms proxy comment. I think Tom was suggesting it for the
userstreams functionality. As userstreams require a long poll
connection there are various other obstacles to overcome if it were to
be run from within the browser directly. In addition, userstreams are
for single user use and not suitable for web applications where
multiple users interact. Instead the something like the Site Streams
service (currently in beta) could be better suited.



On Wed, Oct 6, 2010 at 5:18 PM, Matthew Terenzio <mteren...@gmail.com> wrote:
> So yes, I was correct (at least with search) that a web based solution is
> severely limited compared to a desktop. It will share usage among all it's
> users while a desktop client can spread the load amongst its users IPs. That
> stinks in my opinion. (I'm a web developer.)
>
> On Wed, Oct 6, 2010 at 7:44 PM, Matt Harris <thematthar...@twitter.com>
> wrote:
>>
>> All the information about rate limits can be found on our developer site:
>>    http://dev.twitter.com/pages/rate-limiting
>>
>> When talking about rate limits it is important to be clear about the
>> API being used, as each has their own.
>>
>> For the REST API (requests to api.twitter.com) the limit is 150
>> requests per hour unauthenticated and 350 request per hour for an
>> authenticated user. When you make an authenticated request the users
>> rate limit is affected, not the IPs.
>> The Search API has it's own rate limit based on the IP the request
>> comes from. There is no authenticating for Search so all requests are
>> IP rate limited.
>> The Streaming APIs do not have rate limits in the same way. For the
>> Streaming API the rate limit is controlled by the predicate limits
>> (5,000 user ids etc) and the allowed sampling rate (1% etc).
>>
>> I hope that clarifies how the rate limits apply.
>>
>> Best
>> @themattharris
>> Developer Advocate, Twitter
>> http://twitter.com/themattharris
>>
>>
>>
>> On Wed, Oct 6, 2010 at 3:28 PM, Matthew Terenzio <mteren...@gmail.com>
>> wrote:
>> >
>> >
>> > On Wed, Oct 6, 2010 at 5:48 PM, Tom van der Woerdt <i...@tvdw.eu> wrote:
>> >>
>> >> I will indeed correct you: rate limits are based on account when using
>> >> oauth.
>> >
>> > Really? Can someone second that. I re-read the documentation and it
>> > doesn't
>> > look like it to me. Are the IP limits ignored when you log in as a user.
>> > I
>> > know that is the case for the REST api in most cases but I'm talking
>> > about
>> > streaming and search.
>> >
>> >
>> >>
>> >> Tom
>> >>
>> >>
>> >> On Oct 6, 2010, at 11:39 PM, Matthew Terenzio <mteren...@gmail.com>
>> >> wrote:
>> >>
>> >>
>> >>>
>> >>> There would be one more issue which requires mentioning: JavaScript's
>> >>> "Same-origin policy". You can't make a request directly to the Twitter
>> >>> API via JavaScript: you *will* need a proxy on your own server.
>> >>>
>> >>
>> >> Which seems to put web developers at a sever disadvantage for search
>> >> and
>> >> streaming APIs since rate limits are based on IP addresses. Meaning all
>> >> my
>> >> web users count as one whereas the rate limiting is spread out among
>> >> all the
>> >> users a given desktop client. I asked a while back about this and
>> >> didn't get
>> >> a response.  It just don't seem fair. Seems impossible to build a web
>> >> app of
>> >> anything more than a couple hundred users if those users want to use
>> >> search
>> >> and or streaming. Or correct me.
>> >>
>> >> --
>> >> Twitter developer documentation and resources:
>> >> http://dev.twitter.com/doc
>> >> API updates via Twitter: http://twitter.com/twitterapi
>> >> Issues/Enhancements Tracker:
>> >> http://code.google.com/p/twitter-api/issues/list
>> >> Change your membership to this group:
>> >> http://groups.google.com/group/twitter-development-talk
>> >>
>> >> --
>> >> Twitter developer documentation and resources:
>> >> http://dev.twitter.com/doc
>> >> API updates via Twitter: http://twitter.com/twitterapi
>> >> Issues/Enhancements Tracker:
>> >> http://code.google.com/p/twitter-api/issues/list
>> >> Change your membership to this group:
>> >> http://groups.google.com/group/twitter-development-talk
>> >
>> > --
>> > Twitter developer documentation and resources:
>> > http://dev.twitter.com/doc
>> > API updates via Twitter: http://twitter.com/twitterapi
>> > Issues/Enhancements Tracker:
>> > http://code.google.com/p/twitter-api/issues/list
>> > Change your membership to this group:
>> > http://groups.google.com/group/twitter-development-talk
>> >
>>
>> --
>> Twitter developer documentation and resources: http://dev.twitter.com/doc
>> API updates via Twitter: http://twitter.com/twitterapi
>> Issues/Enhancements Tracker:
>> http://code.google.com/p/twitter-api/issues/list
>> Change your membership to this group:
>> http://groups.google.com/group/twitter-development-talk
>
> --
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker:
> http://code.google.com/p/twitter-api/issues/list
> Change your membership to this group:
> http://groups.google.com/group/twitter-development-talk
>

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Reply via email to