(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.
On Wed, Apr 1, 2009 at 6: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.
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.
> Does this include the Social Graph API methods?
> Jesse
> On Wed, Apr 1, 2009 at 6: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.
On Wed, Apr 1, 2009 at 17:54, Jesse Stay <jesses...@gmail.com> wrote: > Does this include the Social Graph API methods? > Jesse
> On Wed, Apr 1, 2009 at 6: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.
> 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.
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.
> (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.
> 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.
> 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.
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> <id>756264</id> <name>Damon Clinkscales</name> <screen_name>damon</screen_name> <location>Austin, TX</location> <description>I'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_url>https://s3.amazonaws.com/twitter_production/profile_images/73617066/m...</profile_image_url> <url>http://damonc.com</url> <protected>false</protected> <followers_count>974</followers_count> <status> <created_at>Wed Apr 01 21:16:29 +0000 2009</created_at> <id>1434142066</id> <text>RT @ev on April Fools - There is no Twitter Pro</text> <source><a href="http://iconfactory.com/software/twitterrific">twitterrific</a></source> <truncated>false</truncated> <in_reply_to_status_id></in_reply_to_status_id> <in_reply_to_user_id></in_reply_to_user_id> <favorited>false</favorited> <in_reply_to_screen_name></in_reply_to_screen_name> </status> </user>
> (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.
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."
> 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.
> 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.
> 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.
> 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.
> > 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.
> 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.
> > 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 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:
> > 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.
> * 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)
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.
> 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.
> 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.
> > 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.
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.
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.
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?
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.
> 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?
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,
> > 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?
|
