Just wanted to mention-- updated my app to use these new methods, and
now one routine that took OVER 14 minutes to run is now under 1
minute... what an excellent difference. Thanks y'all. -Eric
On Feb 3, 5:01 pm, Alex Payne wrote:
> Happy to announce two new API methods today, delivered in resp
I was really looking forward to implementing these API methods. After
dealing with the pagination for so long, this seemed perfect. Then I
realized that I have to call "/users/show" for every user to get the
most current bio etc. So instead of making 10 calls for a user with
1,000 followers, I'
http://code.google.com/p/twitter-api/issues/detail?id=271
Cheers.
-Stuart
2009/2/7 Alex Payne :
> If you file a ticket, I can check with our engineers to see how performance
> would look if we try to support that filter on the collection we return.
>
> On Sat, Feb 7, 2009 at 11:53, Stuart wrot
If you file a ticket, I can check with our engineers to see how performance
would look if we try to support that filter on the collection we return.
On Sat, Feb 7, 2009 at 11:53, Stuart wrote:
>
> Loving these new methods, but was disappointed to see that they don't
> support the If-Modified-Sin
Loving these new methods, but was disappointed to see that they don't
support the If-Modified-Since header. Any chance of that to reduce
data transfer at both ends and unnecessary processing at our end?
-Stuart
2009/2/4 Alex Payne :
>
> Happy to announce two new API methods today, delivered in r
On Feb 6, 3:38 pm, dougw wrote:
> Ninjamonk, I second what you are asking for here: a search API
> addition to allow ids as valid queries.
It would be a good start if the user_id used in the search API were
the same as the user_id in the rest of the API :)
Scheduled for V2 apparently ...
Sylvai
I haven't tried it out yet, but it's exactly what I needed. Thanks!
On Feb 3, 8:01 pm, Alex Payne wrote:
> Happy to announce two new API methods today, delivered in response to
> developer demand for an easier way to keep tabs on users' social graphs.
> The methods, /friends/ids and /followers/i
Ninjamonk, I second what you are asking for here: a search API
addition to allow ids as valid queries.
In my code, I represent users by their static ids rather than their
screen_names but when doing a search I have to convert back. It would
be nice to have the flexability to do search through bot
sorry badly put, I meant via user id, search via user id so like FROM:
342342342 etc returns the same as say FROM: ninjamonk.
On Feb 5, 10:49 pm, Alex Payne wrote:
> You can presently look up usernames in the Search API. What in
> particular are you looking for?
>
>
>
> Ninjamonk wrote:
> > Hey
You can presently look up usernames in the Search API. What in
particular are you looking for?
Ninjamonk wrote:
Hey Alex, any chance of adding a way of looking up the user name to
the search api instead then?
On Feb 5, 6:19 pm, Alex Payne wrote:
The reason why we can provide the list o
Hey Alex, any chance of adding a way of looking up the user name to
the search api instead then?
On Feb 5, 6:19 pm, Alex Payne wrote:
> The reason why we can provide the list of IDs without any pagination is
> that it comes directly from our denormalized list data store, and
> requires no joinin
Perhaps a better solution might be the ability to pass multiple IDs to
the user/show method so you could retrieve the details of more than
one user in one request, maybe with a limit to the maximum you can get
in one go.
-Stuart
2009/2/5 Alex Payne :
>
> The reason why we can provide the list of
The reason why we can provide the list of IDs without any pagination is
that it comes directly from our denormalized list data store, and
requires no joining, either in SQL or at the application layer. As soon
as we pull in data like screen_name that's sitting elsewhere in our
architecture, t
For all those wanting id AND username attributes to be returned with
these new methods, be sure to head over to
http://code.google.com/p/twitter-api/issues/detail?id=265 and vote
(click the star) to signal your support.
@dougw
On Feb 5, 11:40 am, jstrellner wrote:
> Thanks Alex,
>
> I too, woul
Thanks Alex,
I too, would like to see this return userids AND usernames.
-Joel
On Feb 3, 5:01 pm, Alex Payne wrote:
> Happy to announce two new API methods today, delivered in response to
> developer demand for an easier way to keep tabs on users' social graphs.
> The methods, /friends/ids and
Very cool - these are exactly the methods I was looking for to do some
diff stuff.
I noticed, though, that an API call fails for a protected user's
friends/followers IDs, even though I can browse to that same person's
friends and followers on the HTML side. Is this on purpose? Would love
to be ab
On 2/5/09, Ninjamonk wrote:
> This is really useful, however would be even more useful if you
> offered an unrate limited service to return the username for each
> userid.
> On Feb 5, 3:07 am, James Deville wrote:
> > Any chance of a easy way to map this to usernames? We want the friends l
This is really useful, however would be even more useful if you
offered an unrate limited service to return the username for each
userid.
Problems I foresee.
1 user uses your web based app and the user has 10k followers and 10k
friends and thats your limit used up for the hour.
Even with caching
Any chance of a easy way to map this to usernames? We want the friends list
for Witty (and I imagine others), but we don't need full profiles, just this
+ username. This won't help us otherwise since we'll need to map the entire
list to usernames, which will require too many requests.
JD
On Wed,
On Wed, Feb 4, 2009 at 1:07 PM, Burhan TANWEER wrote:
> Wonderful news !!!
>
> We will be using for our social search engine application. Thanks for
> coming up with these new API for friends and followers ids. I apprecaite it.
>
> On Tue, Feb 3, 2009 at 8:01 PM, Alex Payne wrote:
>
>>
>> Happ
The response should be ordered with most recent followed/followers first
in the list.
Another developer noted duplicates; we'll look into that.
Matt K. wrote:
Alex -
This is a great addition to the API - will make things much easier.
Quick question (and I apologize if this is already docum
I'm getting duplicates in some of my calls to these methods. I've only
seen it happen in those with a very large number of followers
http://twitter.com/Wossy - 56, 000 followers with 11 duplicates.
http://twitter.com/stephenfry - 120, 000 followers with 164
duplicates.
http://twitter.com/kevinros
Awesome. I still do downloads of follower lists because it is an easier way
to get a batch of
information from the profile data than requesting every single one, but this
already is a huge advancement.
Small suggestion: Add a last changed info to it for social graph change or a
number?
Like if I
Wonderful news !!!
We will be using for our social search engine application. Thanks for coming
up with these new API for friends and followers ids. I apprecaite it.
On Tue, Feb 3, 2009 at 8:01 PM, Alex Payne wrote:
>
> Happy to announce two new API methods today, delivered in response to
> de
This is great news. Will make life much easier for a lot of people.
Thanks!
On Feb 4, 4:19 am, rhysmeister wrote:
> A great addition to the API. Thanks for lsitening!
>
> Rhys
>
> On Feb 4, 1:01 am, Alex Payne wrote:
>
> > Happy to announce two new API methods today, delivered in response to
>
A great addition to the API. Thanks for lsitening!
Rhys
On Feb 4, 1:01 am, Alex Payne wrote:
> Happy to announce two new API methods today, delivered in response to
> developer demand for an easier way to keep tabs on users' social graphs.
> The methods, /friends/ids and /followers/ids, return
Just wanted to supply sample output for the curious:
curl --basic --user dougw:PASSWORD http://twitter.com/followers/ids.xml
2396591
13348
6014732
9300822
@dougw
On Feb 3, 11:17 pm, "Matt K." wrote:
> Alex -
>
> This is a great addition to the API - will make things much easier.
>
> Quick q
Alex -
This is a great addition to the API - will make things much easier.
Quick question (and I apologize if this is already documented): do the
followers / friends always come in descending order of when they
friendship/follow was created? In other words will the most recent
follow/friend alwa
Well done Alex. While the 20k requests/hr API limit will still limit the
number of users we are able to have as we grow larger down the road, this
will make a huge difference for us and let us keep growing for much longer.
Also, I like that this encourages apps not to rely on the username of a
per
It is working fine for me.
This is very useful, thanks!
I have a question about created_at. I couldn't find a definition in the
documentation.
Are all the created_at data standardized on GMT or does it vary on the user
location?
It looks like GMT but I still get some weird results mixed with valid
hey! awesome news. I'm reworking my code to use user IDs so this will
help a lot. thanks much. E
On Feb 3, 5:01 pm, Alex Payne wrote:
> Happy to announce two new API methods today, delivered in response to
> developer demand for an easier way to keep tabs on users' social graphs.
> The methods,
Mmmh, I may have spoken a little too soon ...
* As I mentionned, I must provide a login / password to do the call
* Whatever id/screen_name I ask for, I always get MY list of friend /
follower and not the one I asked.
Is anybody getting this ?
Ack, yes, we caught that just after it went out. Currently pushing out a
fix that didn't make it into our earlier deploy.
Sylvain Munaut wrote:
Great ! Thanks a lot.
Small details, when no credential is provided, the follower method
correctly return 'could not authenticate you' while the fri
Great ! Thanks a lot.
Small details, when no credential is provided, the follower method
correctly return 'could not authenticate you' while the friends method
return a HTML error page.
Sylvain
Alex Payne wrote:
> Happy to announce two new API methods today, delivered in response to
> developer
Happy to announce two new API methods today, delivered in response to
developer demand for an easier way to keep tabs on users' social graphs.
The methods, /friends/ids and /followers/ids, return the entire list of
numeric user IDs for a user's set of followed and following users,
respectivel
35 matches
Mail list logo
