[twitter-dev] Re: API Changes for April 1, 2009
Doug? Anyone? Thanks, Marco 2009/4/9 Marco Kaiser kaiser.ma...@gmail.com I recognize an odd behavior for the following property of embedded user object in the friends timeline (XML format). As I understand from the API docs, following should indicate whether the authenticating user is following the returned user. Obviously, all tweets returned on the /statuses/friends_timeline.xml endpoint should come from users I am following (and I manually verified that for some samples), but still some of them have followingfalse/following set. It seems to be at least consistant in a way that the same user always has the same value set for following in a result set - it just is either always wrong or always right. Is that a known issue? Thanks, Marco 2009/4/5 Martin Dufort martin.duf...@gmail.com I'm seeing inconsitent user attributes within the *same* request for the *same* user. One result has full attributes disclosure, and the other one has not. I've updated Issue 409 with my results. Martin On Apr 2, 8:36 pm, Doug Williams d...@twitter.com wrote: Jeffery, This is valid criticism. This bug came as a surprise to us as well. We otherwise would have given developers fair warning. Unfortunately there is no easy fix, and like a bad heart-break, time may be the only answer. In short, the problem is with the user data cache. To get the extended information into that cache, the user object must either expire or be invalidated through some user initiated update. The expiry on the cache is rather long and you will find that inactive accounts will have abbreviated data for up to 2 weeks. This is obviously sub-optimal, as Matt would say. Doug Williams Twitter API Supporthttp://twitter.com/dougw On Thu, Apr 2, 2009 at 12:27 PM, Jeffrey Greenberg jeffreygreenb...@gmail.com wrote: Doug, Grumble: just to say it, this wasn't handled well at all. The fact that this field disappears whether due to caching or through a coding error has the same result of completely breaking my app. How long will it take for this issue to clear up? Days? How many exactly? and after X days will further requests be populated correctly? thx, jeffrey http://www.tweettronics.com
[twitter-dev] Re: API Changes for April 1, 2009
Hi there, This sounds like it is related to Google Code issue 474 [1]. Please visit Google Code and click on the little star next to the title to get updates when that issue is updated. Thanks; — Matt Sanford [1] - http://code.google.com/p/twitter-api/issues/detail?id=474 On Apr 21, 2009, at 04:22 AM, Marco Kaiser wrote: Doug? Anyone? Thanks, Marco 2009/4/9 Marco Kaiser kaiser.ma...@gmail.com I recognize an odd behavior for the following property of embedded user object in the friends timeline (XML format). As I understand from the API docs, following should indicate whether the authenticating user is following the returned user. Obviously, all tweets returned on the /statuses/friends_timeline.xml endpoint should come from users I am following (and I manually verified that for some samples), but still some of them have followingfalse/following set. It seems to be at least consistant in a way that the same user always has the same value set for following in a result set - it just is either always wrong or always right. Is that a known issue? Thanks, Marco 2009/4/5 Martin Dufort martin.duf...@gmail.com I'm seeing inconsitent user attributes within the *same* request for the *same* user. One result has full attributes disclosure, and the other one has not. I've updated Issue 409 with my results. Martin On Apr 2, 8:36 pm, Doug Williams d...@twitter.com wrote: Jeffery, This is valid criticism. This bug came as a surprise to us as well. We otherwise would have given developers fair warning. Unfortunately there is no easy fix, and like a bad heart-break, time may be the only answer. In short, the problem is with the user data cache. To get the extended information into that cache, the user object must either expire or be invalidated through some user initiated update. The expiry on the cache is rather long and you will find that inactive accounts will have abbreviated data for up to 2 weeks. This is obviously sub-optimal, as Matt would say. Doug Williams Twitter API Supporthttp://twitter.com/dougw On Thu, Apr 2, 2009 at 12:27 PM, Jeffrey Greenberg jeffreygreenb...@gmail.com wrote: Doug, Grumble: just to say it, this wasn't handled well at all. The fact that this field disappears whether due to caching or through a coding error has the same result of completely breaking my app. How long will it take for this issue to clear up? Days? How many exactly? and after X days will further requests be populated correctly? thx, jeffrey http://www.tweettronics.com
[twitter-dev] Re: API Changes for April 1, 2009
I recognize an odd behavior for the following property of embedded user object in the friends timeline (XML format). As I understand from the API docs, following should indicate whether the authenticating user is following the returned user. Obviously, all tweets returned on the /statuses/friends_timeline.xml endpoint should come from users I am following (and I manually verified that for some samples), but still some of them have followingfalse/following set. It seems to be at least consistant in a way that the same user always has the same value set for following in a result set - it just is either always wrong or always right. Is that a known issue? Thanks, Marco 2009/4/5 Martin Dufort martin.duf...@gmail.com I'm seeing inconsitent user attributes within the *same* request for the *same* user. One result has full attributes disclosure, and the other one has not. I've updated Issue 409 with my results. Martin On Apr 2, 8:36 pm, Doug Williams d...@twitter.com wrote: Jeffery, This is valid criticism. This bug came as a surprise to us as well. We otherwise would have given developers fair warning. Unfortunately there is no easy fix, and like a bad heart-break, time may be the only answer. In short, the problem is with the user data cache. To get the extended information into that cache, the user object must either expire or be invalidated through some user initiated update. The expiry on the cache is rather long and you will find that inactive accounts will have abbreviated data for up to 2 weeks. This is obviously sub-optimal, as Matt would say. Doug Williams Twitter API Supporthttp://twitter.com/dougw On Thu, Apr 2, 2009 at 12:27 PM, Jeffrey Greenberg jeffreygreenb...@gmail.com wrote: Doug, Grumble: just to say it, this wasn't handled well at all. The fact that this field disappears whether due to caching or through a coding error has the same result of completely breaking my app. How long will it take for this issue to clear up? Days? How many exactly? and after X days will further requests be populated correctly? thx, jeffrey http://www.tweettronics.com
[twitter-dev] Re: API Changes for April 1, 2009
I'm seeing inconsitent user attributes within the *same* request for the *same* user. One result has full attributes disclosure, and the other one has not. I've updated Issue 409 with my results. Martin On Apr 2, 8:36 pm, Doug Williams d...@twitter.com wrote: Jeffery, This is valid criticism. This bug came as a surprise to us as well. We otherwise would have given developers fair warning. Unfortunately there is no easy fix, and like a bad heart-break, time may be the only answer. In short, the problem is with the user data cache. To get the extended information into that cache, the user object must either expire or be invalidated through some user initiated update. The expiry on the cache is rather long and you will find that inactive accounts will have abbreviated data for up to 2 weeks. This is obviously sub-optimal, as Matt would say. Doug Williams Twitter API Supporthttp://twitter.com/dougw On Thu, Apr 2, 2009 at 12:27 PM, Jeffrey Greenberg jeffreygreenb...@gmail.com wrote: Doug, Grumble: just to say it, this wasn't handled well at all. The fact that this field disappears whether due to caching or through a coding error has the same result of completely breaking my app. How long will it take for this issue to clear up? Days? How many exactly? and after X days will further requests be populated correctly? thx, jeffrey http://www.tweettronics.com
[twitter-dev] Re: API Changes for April 1, 2009
Simply a user show. http://twitter.com/users/show/ccfcrule.xml is still returning the same data as earlier. On Apr 1, 10:23 pm, Alex Payne a...@twitter.com wrote: From what method calls? On Wed, Apr 1, 2009 at 19:23, Damon P. Cortesi d.lifehac...@gmail.com wrote: I'm not sure if it's related to this push, but I've started to get several user objects back with no statuses_updates. This is a somewhat blocking bug for TweetStats as I try to verify they have tweets while verifying the account. Though I can just try to enumerate through and will probably have to do an emergency update to do so. here's a sample user object I'm getting back: ?xml version=1.0 encoding=UTF-8? user id20176857/id nameJonny Beasley/name screen_nameccfcrule/screen_name location/location description/description profile_image_urlhttp://s3.amazonaws.com/twitter_production/ profile_images/78298843/Me_With_Cap_normal.jpg/profile_image_url url/url protectedfalse/protected followers_count25/followers_count status created_atSat Mar 28 20:00:26 + 2009/created_at id1408524555/id textChecking out my TweetStats!http://tweetstats.com/graphs/ccfcrule/text sourcelt;a href=quot;http:// tweetstats.comquot;gt;TweetStatslt;/agt;/source truncatedfalse/truncated in_reply_to_status_id/in_reply_to_status_id in_reply_to_user_id/in_reply_to_user_id favoritedfalse/favorited in_reply_to_screen_name/in_reply_to_screen_name /status /user dpc On Apr 1, 5:34 pm, Alex Payne a...@twitter.com wrote: (Not an April Fool, we promise. We don't enjoy humor.) * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. A bit more about this change: Previously, these full User objects were only available via the /users/show and /account/verify_credentials methods. If your application has been making requests to these methods just to get extra User attributes, you no longer need to do so. We've had many, many requests for these extra attributes to be available everywhere, so we hope to see you all making use of them! Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. Please also note that if your application is operating in a highly bandwidth-constrained environment, you may want to proxy requests to strip out attributes that aren't relevant to your client. The additional bytes over the wire should not impact the vast majority of platforms, in our estimates. As always, you can keep up with these changes athttp://bit.ly/api_changelog. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
[twitter-dev] Re: API Changes for April 1, 2009
On Apr 1, 10:15 pm, Chad Etzel jazzyc...@gmail.com wrote: On Thu, Apr 2, 2009 at 1:10 AM, Adrian spiritpo...@gmail.com wrote: As of right right now:http://twitter.com/users/show/bob.xml has about twice the amount of information as say: http://twitter.com/users/show/WeezerOfficial.xml FTA: Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. -Chad Right, but the odd thing is this is data that was showing up normally before. When this change went into effect, I started getting a lot of users with no statuses_count showing whereas prior to the change that was a reliable property of the user object.
[twitter-dev] Re: API Changes for April 1, 2009
I'm having the same issue here. The /users/show method is now returning the basic user element for some users. Weird. Jochem On Apr 2, 8:10 am, Damon P. Cortesi d.lifehac...@gmail.com wrote: On Apr 1, 10:15 pm, Chad Etzel jazzyc...@gmail.com wrote: On Thu, Apr 2, 2009 at 1:10 AM, Adrian spiritpo...@gmail.com wrote: As of right right now:http://twitter.com/users/show/bob.xml has about twice the amount of information as say: http://twitter.com/users/show/WeezerOfficial.xml FTA: Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. -Chad Right, but the odd thing is this is data that was showing up normally before. When this change went into effect, I started getting a lot of users with no statuses_count showing whereas prior to the change that was a reliable property of the user object.
[twitter-dev] Re: API Changes for April 1, 2009
I am facing the same issue too with the API http://twitter.com/users/ show/id.xml. Now the big problem is that in some cases following fields are missing: friends_count created_at favourites_count utc_offset time_zone profile_background_image_url statuses_count Due to this my application buzzom.com has broken down. Is there an alternate way of getting these fields for a particular user? Please suggest. Regards, Binit On Apr 2, 11:10 am, Damon P. Cortesi d.lifehac...@gmail.com wrote: On Apr 1, 10:15 pm, Chad Etzel jazzyc...@gmail.com wrote: On Thu, Apr 2, 2009 at 1:10 AM, Adrian spiritpo...@gmail.com wrote: As of right right now:http://twitter.com/users/show/bob.xml has about twice the amount of information as say: http://twitter.com/users/show/WeezerOfficial.xml FTA: Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. -Chad Right, but the odd thing is this is data that was showing up normally before. When this change went into effect, I started getting a lot of users with no statuses_count showing whereas prior to the change that was a reliable property of the user object.
[twitter-dev] Re: API Changes for April 1, 2009
On 4/1/09 8:34 PM, Alex Payne wrote: * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. Sweet jeebus! It's Christmas, all over again! Thanks, Twitter gnomes. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
[twitter-dev] Re: API Changes for April 1, 2009
On Apr 2, 4:04 am, binit binit.th...@gmail.com wrote: Due to this my application buzzom.com has broken down. Is there an alternate way of getting these fields for a particular user? Please suggest. In some cases, even though /users/show does not have the full user object, /statuses/user_timeline will. I've been able to use this as a workaround for some accounts when the fields I need don't exist, but it doesn't work in every case.
[twitter-dev] Re: API Changes for April 1, 2009
On Thu, Apr 2, 2009 at 12:10 AM, Damon P. Cortesi d.lifehac...@gmail.comwrote: On Apr 1, 10:15 pm, Chad Etzel jazzyc...@gmail.com wrote: On Thu, Apr 2, 2009 at 1:10 AM, Adrian spiritpo...@gmail.com wrote: As of right right now:http://twitter.com/users/show/bob.xml has about twice the amount of information as say: http://twitter.com/users/show/WeezerOfficial.xml FTA: Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. -Chad Right, but the odd thing is this is data that was showing up normally before. When this change went into effect, I started getting a lot of users with no statuses_count showing whereas prior to the change that was a reliable property of the user object. I'm seeing similar from our users on SocialToo. Jesse
[twitter-dev] Re: API Changes for April 1, 2009
The loss of fields (issue 409) is the result of the caching issue described above. You should see these fields reappear as the cache user objects expire. Doug Williams Twitter API Support http://twitter.com/dougw On Thu, Apr 2, 2009 at 10:40 AM, binit binit.th...@gmail.com wrote: Thanks a lot, Damon. It works! You saved my day :) On Apr 2, 8:35 pm, Damon P. Cortesi d.lifehac...@gmail.com wrote: On Apr 2, 4:04 am, binit binit.th...@gmail.com wrote: Due to this my application buzzom.com has broken down. Is there an alternate way of getting these fields for a particular user? Please suggest. In some cases, even though /users/show does not have the full user object, /statuses/user_timeline will. I've been able to use this as a workaround for some accounts when the fields I need don't exist, but it doesn't work in every case.
[twitter-dev] Re: API Changes for April 1, 2009
Jeffery, This is valid criticism. This bug came as a surprise to us as well. We otherwise would have given developers fair warning. Unfortunately there is no easy fix, and like a bad heart-break, time may be the only answer. In short, the problem is with the user data cache. To get the extended information into that cache, the user object must either expire or be invalidated through some user initiated update. The expiry on the cache is rather long and you will find that inactive accounts will have abbreviated data for up to 2 weeks. This is obviously sub-optimal, as Matt would say. Doug Williams Twitter API Support http://twitter.com/dougw On Thu, Apr 2, 2009 at 12:27 PM, Jeffrey Greenberg jeffreygreenb...@gmail.com wrote: Doug, Grumble: just to say it, this wasn't handled well at all. The fact that this field disappears whether due to caching or through a coding error has the same result of completely breaking my app. How long will it take for this issue to clear up? Days? How many exactly? and after X days will further requests be populated correctly? thx, jeffrey http://www.tweettronics.com
[twitter-dev] Re: API Changes for April 1, 2009
Fantastic news. Are the direct message's recipient and sender objects updated as well? Zac Bowling http://twitter.com/zbowling On Wed, Apr 1, 2009 at 5:34 PM, Alex Payne a...@twitter.com wrote: (Not an April Fool, we promise. We don't enjoy humor.) * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. A bit more about this change: Previously, these full User objects were only available via the /users/show and /account/verify_credentials methods. If your application has been making requests to these methods just to get extra User attributes, you no longer need to do so. We've had many, many requests for these extra attributes to be available everywhere, so we hope to see you all making use of them! Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. Please also note that if your application is operating in a highly bandwidth-constrained environment, you may want to proxy requests to strip out attributes that aren't relevant to your client. The additional bytes over the wire should not impact the vast majority of platforms, in our estimates. As always, you can keep up with these changes at http://bit.ly/api_changelog. -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: API Changes for April 1, 2009
Egads! No, they aren't, but that's a quick fix. Will have it out tomorrow, hopefully, Monday at the latest. On Wed, Apr 1, 2009 at 17:57, Zac Bowling zbowl...@gmail.com wrote: Fantastic news. Are the direct message's recipient and sender objects updated as well? Zac Bowling http://twitter.com/zbowling On Wed, Apr 1, 2009 at 5:34 PM, Alex Payne a...@twitter.com wrote: (Not an April Fool, we promise. We don't enjoy humor.) * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. A bit more about this change: Previously, these full User objects were only available via the /users/show and /account/verify_credentials methods. If your application has been making requests to these methods just to get extra User attributes, you no longer need to do so. We've had many, many requests for these extra attributes to be available everywhere, so we hope to see you all making use of them! Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. Please also note that if your application is operating in a highly bandwidth-constrained environment, you may want to proxy requests to strip out attributes that aren't relevant to your client. The additional bytes over the wire should not impact the vast majority of platforms, in our estimates. As always, you can keep up with these changes at http://bit.ly/api_changelog. -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: API Changes for April 1, 2009
I'm not sure if it's related to this push, but I've started to get several user objects back with no statuses_updates. This is a somewhat blocking bug for TweetStats as I try to verify they have tweets while verifying the account. Though I can just try to enumerate through and will probably have to do an emergency update to do so. here's a sample user object I'm getting back: ?xml version=1.0 encoding=UTF-8? user id20176857/id nameJonny Beasley/name screen_nameccfcrule/screen_name location/location description/description profile_image_urlhttp://s3.amazonaws.com/twitter_production/ profile_images/78298843/Me_With_Cap_normal.jpg/profile_image_url url/url protectedfalse/protected followers_count25/followers_count status created_atSat Mar 28 20:00:26 + 2009/created_at id1408524555/id textChecking out my TweetStats! http://tweetstats.com/graphs/ccfcrule/text sourcelt;a href=quot;http:// tweetstats.comquot;gt;TweetStatslt;/agt;/source truncatedfalse/truncated in_reply_to_status_id/in_reply_to_status_id in_reply_to_user_id/in_reply_to_user_id favoritedfalse/favorited in_reply_to_screen_name/in_reply_to_screen_name /status /user dpc On Apr 1, 5:34 pm, Alex Payne a...@twitter.com wrote: (Not an April Fool, we promise. We don't enjoy humor.) * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. A bit more about this change: Previously, these full User objects were only available via the /users/show and /account/verify_credentials methods. If your application has been making requests to these methods just to get extra User attributes, you no longer need to do so. We've had many, many requests for these extra attributes to be available everywhere, so we hope to see you all making use of them! Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. Please also note that if your application is operating in a highly bandwidth-constrained environment, you may want to proxy requests to strip out attributes that aren't relevant to your client. The additional bytes over the wire should not impact the vast majority of platforms, in our estimates. As always, you can keep up with these changes athttp://bit.ly/api_changelog. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
[twitter-dev] Re: API Changes for April 1, 2009
Sorry, I meant statuses_count. On Apr 1, 7:23 pm, Damon P. Cortesi d.lifehac...@gmail.com wrote: I'm not sure if it's related to this push, but I've started to get several user objects back with no statuses_updates. This is a somewhat blocking bug for TweetStats as I try to verify they have tweets while verifying the account. Though I can just try to enumerate through and will probably have to do an emergency update to do so. here's a sample user object I'm getting back: ?xml version=1.0 encoding=UTF-8? user id20176857/id nameJonny Beasley/name screen_nameccfcrule/screen_name location/location description/description profile_image_urlhttp://s3.amazonaws.com/twitter_production/ profile_images/78298843/Me_With_Cap_normal.jpg/profile_image_url url/url protectedfalse/protected followers_count25/followers_count status created_atSat Mar 28 20:00:26 + 2009/created_at id1408524555/id textChecking out my TweetStats!http://tweetstats.com/graphs/ccfcrule/text sourcelt;a href=quot;http:// tweetstats.comquot;gt;TweetStatslt;/agt;/source truncatedfalse/truncated in_reply_to_status_id/in_reply_to_status_id in_reply_to_user_id/in_reply_to_user_id favoritedfalse/favorited in_reply_to_screen_name/in_reply_to_screen_name /status /user dpc On Apr 1, 5:34 pm, Alex Payne a...@twitter.com wrote: (Not an April Fool, we promise. We don't enjoy humor.) * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. A bit more about this change: Previously, these full User objects were only available via the /users/show and /account/verify_credentials methods. If your application has been making requests to these methods just to get extra User attributes, you no longer need to do so. We've had many, many requests for these extra attributes to be available everywhere, so we hope to see you all making use of them! Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. Please also note that if your application is operating in a highly bandwidth-constrained environment, you may want to proxy requests to strip out attributes that aren't relevant to your client. The additional bytes over the wire should not impact the vast majority of platforms, in our estimates. As always, you can keep up with these changes athttp://bit.ly/api_changelog. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
[twitter-dev] Re: API Changes for April 1, 2009
On Wed, Apr 1, 2009 at 9:33 PM, Damon P. Cortesi d.lifehac...@gmail.com wrote: I'm not sure if it's related to this push, but I've started to get several user objects back with no statuses_updates. Sorry, I meant statuses_count. nor favourites_count, nor friends_count... here's my record, in full (from /users/show/damon.xml) $ curl http://twitter.com/users/show/damon.xml ?xml version=1.0 encoding=UTF-8? user id756264/id nameDamon Clinkscales/name screen_namedamon/screen_name locationAustin, TX/location descriptionI'm a shepherd. Software engineer at VitalSource and leader of Austin On Rails. I also build apps like http://snaptweet.com and http://doesfollow.com. /description profile_image_urlhttps://s3.amazonaws.com/twitter_production/profile_images/73617066/me_smile_normal.jpg/profile_image_url urlhttp://damonc.com/url protectedfalse/protected followers_count974/followers_count status created_atWed Apr 01 21:16:29 + 2009/created_at id1434142066/id textRT @ev on April Fools - There is no Twitter Pro/text sourcelt;a href=http://iconfactory.com/software/twitterrificgt;twitterrificlt;/agt;/source truncatedfalse/truncated in_reply_to_status_id/in_reply_to_status_id in_reply_to_user_id/in_reply_to_user_id favoritedfalse/favorited in_reply_to_screen_name/in_reply_to_screen_name /status /user April Fools? -damon
[twitter-dev] Re: API Changes for April 1, 2009
As of right right now: http://twitter.com/users/show/bob.xml has about twice the amount of information as say: http://twitter.com/users/show/WeezerOfficial.xml On Apr 2, 3:34 am, Alex Payne a...@twitter.com wrote: (Not an April Fool, we promise. We don't enjoy humor.) * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. A bit more about this change: Previously, these full User objects were only available via the /users/show and /account/verify_credentials methods. If your application has been making requests to these methods just to get extra User attributes, you no longer need to do so. We've had many, many requests for these extra attributes to be available everywhere, so we hope to see you all making use of them! Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. Please also note that if your application is operating in a highly bandwidth-constrained environment, you may want to proxy requests to strip out attributes that aren't relevant to your client. The additional bytes over the wire should not impact the vast majority of platforms, in our estimates. As always, you can keep up with these changes athttp://bit.ly/api_changelog. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
[twitter-dev] Re: API Changes for April 1, 2009
On Thu, Apr 2, 2009 at 1:10 AM, Adrian spiritpo...@gmail.com wrote: As of right right now: http://twitter.com/users/show/bob.xml has about twice the amount of information as say: http://twitter.com/users/show/WeezerOfficial.xml FTA: Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. -Chad On Apr 2, 3:34 am, Alex Payne a...@twitter.com wrote: (Not an April Fool, we promise. We don't enjoy humor.) * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. A bit more about this change: Previously, these full User objects were only available via the /users/show and /account/verify_credentials methods. If your application has been making requests to these methods just to get extra User attributes, you no longer need to do so. We've had many, many requests for these extra attributes to be available everywhere, so we hope to see you all making use of them! Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. Please also note that if your application is operating in a highly bandwidth-constrained environment, you may want to proxy requests to strip out attributes that aren't relevant to your client. The additional bytes over the wire should not impact the vast majority of platforms, in our estimates. As always, you can keep up with these changes athttp://bit.ly/api_changelog. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
[twitter-dev] Re: API Changes for April 1, 2009
From what method calls? On Wed, Apr 1, 2009 at 19:23, Damon P. Cortesi d.lifehac...@gmail.com wrote: I'm not sure if it's related to this push, but I've started to get several user objects back with no statuses_updates. This is a somewhat blocking bug for TweetStats as I try to verify they have tweets while verifying the account. Though I can just try to enumerate through and will probably have to do an emergency update to do so. here's a sample user object I'm getting back: ?xml version=1.0 encoding=UTF-8? user id20176857/id nameJonny Beasley/name screen_nameccfcrule/screen_name location/location description/description profile_image_urlhttp://s3.amazonaws.com/twitter_production/ profile_images/78298843/Me_With_Cap_normal.jpg/profile_image_url url/url protectedfalse/protected followers_count25/followers_count status created_atSat Mar 28 20:00:26 + 2009/created_at id1408524555/id textChecking out my TweetStats! http://tweetstats.com/graphs/ccfcrule/text sourcelt;a href=quot;http:// tweetstats.comquot;gt;TweetStatslt;/agt;/source truncatedfalse/truncated in_reply_to_status_id/in_reply_to_status_id in_reply_to_user_id/in_reply_to_user_id favoritedfalse/favorited in_reply_to_screen_name/in_reply_to_screen_name /status /user dpc On Apr 1, 5:34 pm, Alex Payne a...@twitter.com wrote: (Not an April Fool, we promise. We don't enjoy humor.) * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. A bit more about this change: Previously, these full User objects were only available via the /users/show and /account/verify_credentials methods. If your application has been making requests to these methods just to get extra User attributes, you no longer need to do so. We've had many, many requests for these extra attributes to be available everywhere, so we hope to see you all making use of them! Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. Please also note that if your application is operating in a highly bandwidth-constrained environment, you may want to proxy requests to strip out attributes that aren't relevant to your client. The additional bytes over the wire should not impact the vast majority of platforms, in our estimates. As always, you can keep up with these changes athttp://bit.ly/api_changelog. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
