[twitter-dev] Re: API 140 character truncation change?
On Fri, Oct 23, 2009 at 02:24:53PM -0700, AJ Chen wrote: > I noticed this behavior a long time ago (may be a month) and reported the > problem on this list, but it did not get any response from the api team. I > thought it was a bug, but just realized yesterday that the api probably > ignores 140+ chars status update intentionally. but' I'm not sure this is > the policy or temporary tactic to reduce workload on api. it would be good > that api team can clasify on this issue. to check if this happens or not, > you can compare the status sent to api and the status returned from api in > your application code. Note that duplicate statuses are silently failing in the same manner as those over 140 characters. Aside from the already-mentioned issue of Twitter doing automatic bit.ly shortening on URLs, comparing the submitted status to the received status will also produce incorrect results when the submitted status is rejected for being identical to the user's most-recent previous status. Depending on your application, failure in this scenario may or may not be relevant. -- Dave Sherohman
[twitter-dev] Re: API 140 character truncation change?
On Fri, Oct 23, 2009 at 04:20:36PM -0700, Dewald Pretorius wrote: > Instead of all of us having to do fancy tap-dances, the proper > solution is for Twitter to issue an error response when a sent tweet > is rejected for whatever reason. Yep, exactly. That's my big gripe about the whole thing. Failing silently is *never* the right answer in an API or other library code. -- Dave Sherohman
[twitter-dev] Re: API 140 character truncation change?
+1 agreed On Oct 23, 2009, at 7:20 PM, Dewald Pretorius wrote: Instead of all of us having to do fancy tap-dances, the proper solution is for Twitter to issue an error response when a sent tweet is rejected for whatever reason. Dewald On Oct 23, 7:58 pm, AJ Chen wrote: then, comparing the front part (without url at the end) of the status is probably sufficient. -aj On Fri, Oct 23, 2009 at 3:07 PM, Dewald Pretorius wrote: You cannot compare the status sent with the status returned when the status contains an URL. The returned status contains Twitter's own bit.ly shortened URL instead of the URL your status sent had. Dewald On Oct 23, 6:24 pm, AJ Chen wrote: I noticed this behavior a long time ago (may be a month) and reported the problem on this list, but it did not get any response from the api team. I thought it was a bug, but just realized yesterday that the api probably ignores 140+ chars status update intentionally. but' I'm not sure this is the policy or temporary tactic to reduce workload on api. it would be good that api team can clasify on this issue. to check if this happens or not, you can compare the status sent to api and the status returned from api in your application code. -aj On Fri, Oct 23, 2009 at 1:51 PM, Naveen wrote: Here are two threads related to this issue. http://groups.google.com/group/twitter-development-talk/browse_thread . .. http://groups.google.com/group/twitter-development-talk/browse_thread . .. It is an inconvenient change, not because they changed it, but because they did not announce that the change was happening. On Oct 21, 5:37 am, Dave Sherohman wrote: On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote: Has anyone else noticed a change in the way that the 140 character limit is enforced via the API? I noticed a change sometime between the 13th and the 16th that is now causing all my 140+ character posts to be rejected by the API. Also a side note is that the api is not returning errors, they return proper responses however they are the proper response for the current status of the account, not the new status that was just attempted to be posted. My users first reported issues arising from this on the 15th, although I didn't identify the cause until the 17th, at which point I asked about it in #Net::Twitter and Marc Mims brought the question here under the subject line "Bug? Updates > 140 characters return success with prior update payload". See the discussion under that thread for more on it, but the overall upshot is: - This is an intentional (if poorly-announced) change, not a bug. - Status updates are known to be getting silently rejected in this manner both due to exceeding 140 characters and due to violation of the expanded "no duplicates" policy. - Twitter has not stated whether there are any additional circumstances beyond those two cases in which updates will be silently rejected. - Twitter has not stated any plans regarding adding an indicator for when a "200 OK" status update has, in fact, been rejected. I am attempting to compensate for this change by checking the returned status ID against the previous highest-seen ID to determine whether the status returned with the "200 OK" response is a new one or the user's pre-existing status. This seems to work, but does not indicate the reason for the silent failure, so I can't report the cause to my users. Andy Freeman has mentioned that, in the case of rejection due to duplication, this is also unsatisfactory in that it does not allow him to identify the original status which was duplicated. -- Dave Sherohman -- AJ Chen, PhD Chair, Semantic Web SIG, sdforum.orghttp://web2express.org Palo Alto, CA -- AJ Chen, PhD Chair, Semantic Web SIG, sdforum.orghttp://web2express.org Palo Alto, CA
[twitter-dev] Re: API 140 character truncation change?
Instead of all of us having to do fancy tap-dances, the proper solution is for Twitter to issue an error response when a sent tweet is rejected for whatever reason. Dewald On Oct 23, 7:58 pm, AJ Chen wrote: > then, comparing the front part (without url at the end) of the status is > probably sufficient. -aj > > > > On Fri, Oct 23, 2009 at 3:07 PM, Dewald Pretorius wrote: > > > You cannot compare the status sent with the status returned when the > > status contains an URL. The returned status contains Twitter's own > > bit.ly shortened URL instead of the URL your status sent had. > > > Dewald > > > On Oct 23, 6:24 pm, AJ Chen wrote: > > > I noticed this behavior a long time ago (may be a month) and reported the > > > problem on this list, but it did not get any response from the api team. > > I > > > thought it was a bug, but just realized yesterday that the api probably > > > ignores 140+ chars status update intentionally. but' I'm not sure this is > > > the policy or temporary tactic to reduce workload on api. it would be > > good > > > that api team can clasify on this issue. to check if this happens or not, > > > you can compare the status sent to api and the status returned from api > > in > > > your application code. > > > -aj > > > > On Fri, Oct 23, 2009 at 1:51 PM, Naveen wrote: > > > > > Here are two threads related to this issue. > > > > >http://groups.google.com/group/twitter-development-talk/browse_thread. > > .. > > > > >http://groups.google.com/group/twitter-development-talk/browse_thread. > > .. > > > > > It is an inconvenient change, not because they changed it, but because > > > > they did not announce that the change was happening. > > > > > On Oct 21, 5:37 am, Dave Sherohman wrote: > > > > > On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote: > > > > > > Has anyone else noticed a change in the way that the 140 character > > > > > > limit is enforced via the API? I noticed a change sometime between > > the > > > > > > 13th and the 16th that is now causing all my 140+ character posts > > to > > > > > > be rejected by the API. > > > > > > Also a side note is that the api is not returning errors, they > > return > > > > > > proper responses however they are the proper response for the > > current > > > > > > status of the account, not the new status that was just attempted > > to > > > > > > be posted. > > > > > > My users first reported issues arising from this on the 15th, > > although I > > > > > didn't identify the cause until the 17th, at which point I asked > > about > > > > > it in #Net::Twitter and Marc Mims brought the question here under the > > > > > subject line "Bug? Updates > 140 characters return success with prior > > > > > update payload". See the discussion under that thread for more on > > it, > > > > > but the overall upshot is: > > > > > > - This is an intentional (if poorly-announced) change, not a bug. > > > > > - Status updates are known to be getting silently rejected in this > > > > > manner both due to exceeding 140 characters and due to violation of > > > > > the expanded "no duplicates" policy. > > > > > - Twitter has not stated whether there are any additional > > circumstances > > > > > beyond those two cases in which updates will be silently rejected. > > > > > - Twitter has not stated any plans regarding adding an indicator for > > > > > when a "200 OK" status update has, in fact, been rejected. > > > > > > I am attempting to compensate for this change by checking the > > returned > > > > > status ID against the previous highest-seen ID to determine whether > > the > > > > > status returned with the "200 OK" response is a new one or the user's > > > > > pre-existing status. This seems to work, but does not indicate the > > > > > reason for the silent failure, so I can't report the cause to my > > users. > > > > > Andy Freeman has mentioned that, in the case of rejection due to > > > > > duplication, this is also unsatisfactory in that it does not allow > > him > > > > > to identify the original status which was duplicated. > > > > > > -- > > > > > Dave Sherohman > > > > -- > > > AJ Chen, PhD > > > Chair, Semantic Web SIG, sdforum.orghttp://web2express.org > > > Palo Alto, CA > > -- > AJ Chen, PhD > Chair, Semantic Web SIG, sdforum.orghttp://web2express.org > Palo Alto, CA
[twitter-dev] Re: API 140 character truncation change?
then, comparing the front part (without url at the end) of the status is probably sufficient. -aj On Fri, Oct 23, 2009 at 3:07 PM, Dewald Pretorius wrote: > > You cannot compare the status sent with the status returned when the > status contains an URL. The returned status contains Twitter's own > bit.ly shortened URL instead of the URL your status sent had. > > Dewald > > On Oct 23, 6:24 pm, AJ Chen wrote: > > I noticed this behavior a long time ago (may be a month) and reported the > > problem on this list, but it did not get any response from the api team. > I > > thought it was a bug, but just realized yesterday that the api probably > > ignores 140+ chars status update intentionally. but' I'm not sure this is > > the policy or temporary tactic to reduce workload on api. it would be > good > > that api team can clasify on this issue. to check if this happens or not, > > you can compare the status sent to api and the status returned from api > in > > your application code. > > -aj > > > > > > > > On Fri, Oct 23, 2009 at 1:51 PM, Naveen wrote: > > > > > Here are two threads related to this issue. > > > > >http://groups.google.com/group/twitter-development-talk/browse_thread. > .. > > > > >http://groups.google.com/group/twitter-development-talk/browse_thread. > .. > > > > > It is an inconvenient change, not because they changed it, but because > > > they did not announce that the change was happening. > > > > > On Oct 21, 5:37 am, Dave Sherohman wrote: > > > > On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote: > > > > > Has anyone else noticed a change in the way that the 140 character > > > > > limit is enforced via the API? I noticed a change sometime between > the > > > > > 13th and the 16th that is now causing all my 140+ character posts > to > > > > > be rejected by the API. > > > > > Also a side note is that the api is not returning errors, they > return > > > > > proper responses however they are the proper response for the > current > > > > > status of the account, not the new status that was just attempted > to > > > > > be posted. > > > > > > My users first reported issues arising from this on the 15th, > although I > > > > didn't identify the cause until the 17th, at which point I asked > about > > > > it in #Net::Twitter and Marc Mims brought the question here under the > > > > subject line "Bug? Updates > 140 characters return success with prior > > > > update payload". See the discussion under that thread for more on > it, > > > > but the overall upshot is: > > > > > > - This is an intentional (if poorly-announced) change, not a bug. > > > > - Status updates are known to be getting silently rejected in this > > > > manner both due to exceeding 140 characters and due to violation of > > > > the expanded "no duplicates" policy. > > > > - Twitter has not stated whether there are any additional > circumstances > > > > beyond those two cases in which updates will be silently rejected. > > > > - Twitter has not stated any plans regarding adding an indicator for > > > > when a "200 OK" status update has, in fact, been rejected. > > > > > > I am attempting to compensate for this change by checking the > returned > > > > status ID against the previous highest-seen ID to determine whether > the > > > > status returned with the "200 OK" response is a new one or the user's > > > > pre-existing status. This seems to work, but does not indicate the > > > > reason for the silent failure, so I can't report the cause to my > users. > > > > Andy Freeman has mentioned that, in the case of rejection due to > > > > duplication, this is also unsatisfactory in that it does not allow > him > > > > to identify the original status which was duplicated. > > > > > > -- > > > > Dave Sherohman > > > > -- > > AJ Chen, PhD > > Chair, Semantic Web SIG, sdforum.orghttp://web2express.org > > Palo Alto, CA -- AJ Chen, PhD Chair, Semantic Web SIG, sdforum.org http://web2express.org Palo Alto, CA
[twitter-dev] Re: API 140 character truncation change?
You cannot compare the status sent with the status returned when the status contains an URL. The returned status contains Twitter's own bit.ly shortened URL instead of the URL your status sent had. Dewald On Oct 23, 6:24 pm, AJ Chen wrote: > I noticed this behavior a long time ago (may be a month) and reported the > problem on this list, but it did not get any response from the api team. I > thought it was a bug, but just realized yesterday that the api probably > ignores 140+ chars status update intentionally. but' I'm not sure this is > the policy or temporary tactic to reduce workload on api. it would be good > that api team can clasify on this issue. to check if this happens or not, > you can compare the status sent to api and the status returned from api in > your application code. > -aj > > > > On Fri, Oct 23, 2009 at 1:51 PM, Naveen wrote: > > > Here are two threads related to this issue. > > >http://groups.google.com/group/twitter-development-talk/browse_thread... > > >http://groups.google.com/group/twitter-development-talk/browse_thread... > > > It is an inconvenient change, not because they changed it, but because > > they did not announce that the change was happening. > > > On Oct 21, 5:37 am, Dave Sherohman wrote: > > > On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote: > > > > Has anyone else noticed a change in the way that the 140 character > > > > limit is enforced via the API? I noticed a change sometime between the > > > > 13th and the 16th that is now causing all my 140+ character posts to > > > > be rejected by the API. > > > > Also a side note is that the api is not returning errors, they return > > > > proper responses however they are the proper response for the current > > > > status of the account, not the new status that was just attempted to > > > > be posted. > > > > My users first reported issues arising from this on the 15th, although I > > > didn't identify the cause until the 17th, at which point I asked about > > > it in #Net::Twitter and Marc Mims brought the question here under the > > > subject line "Bug? Updates > 140 characters return success with prior > > > update payload". See the discussion under that thread for more on it, > > > but the overall upshot is: > > > > - This is an intentional (if poorly-announced) change, not a bug. > > > - Status updates are known to be getting silently rejected in this > > > manner both due to exceeding 140 characters and due to violation of > > > the expanded "no duplicates" policy. > > > - Twitter has not stated whether there are any additional circumstances > > > beyond those two cases in which updates will be silently rejected. > > > - Twitter has not stated any plans regarding adding an indicator for > > > when a "200 OK" status update has, in fact, been rejected. > > > > I am attempting to compensate for this change by checking the returned > > > status ID against the previous highest-seen ID to determine whether the > > > status returned with the "200 OK" response is a new one or the user's > > > pre-existing status. This seems to work, but does not indicate the > > > reason for the silent failure, so I can't report the cause to my users. > > > Andy Freeman has mentioned that, in the case of rejection due to > > > duplication, this is also unsatisfactory in that it does not allow him > > > to identify the original status which was duplicated. > > > > -- > > > Dave Sherohman > > -- > AJ Chen, PhD > Chair, Semantic Web SIG, sdforum.orghttp://web2express.org > Palo Alto, CA
[twitter-dev] Re: API 140 character truncation change?
I noticed this behavior a long time ago (may be a month) and reported the problem on this list, but it did not get any response from the api team. I thought it was a bug, but just realized yesterday that the api probably ignores 140+ chars status update intentionally. but' I'm not sure this is the policy or temporary tactic to reduce workload on api. it would be good that api team can clasify on this issue. to check if this happens or not, you can compare the status sent to api and the status returned from api in your application code. -aj On Fri, Oct 23, 2009 at 1:51 PM, Naveen wrote: > > Here are two threads related to this issue. > > http://groups.google.com/group/twitter-development-talk/browse_thread/thread/cd95ce07be341223/66c66de585383868#66c66de585383868 > > http://groups.google.com/group/twitter-development-talk/browse_thread/thread/3d6a727892710d5e# > > It is an inconvenient change, not because they changed it, but because > they did not announce that the change was happening. > > On Oct 21, 5:37 am, Dave Sherohman wrote: > > On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote: > > > Has anyone else noticed a change in the way that the 140 character > > > limit is enforced via the API? I noticed a change sometime between the > > > 13th and the 16th that is now causing all my 140+ character posts to > > > be rejected by the API. > > > Also a side note is that the api is not returning errors, they return > > > proper responses however they are the proper response for the current > > > status of the account, not the new status that was just attempted to > > > be posted. > > > > My users first reported issues arising from this on the 15th, although I > > didn't identify the cause until the 17th, at which point I asked about > > it in #Net::Twitter and Marc Mims brought the question here under the > > subject line "Bug? Updates > 140 characters return success with prior > > update payload". See the discussion under that thread for more on it, > > but the overall upshot is: > > > > - This is an intentional (if poorly-announced) change, not a bug. > > - Status updates are known to be getting silently rejected in this > > manner both due to exceeding 140 characters and due to violation of > > the expanded "no duplicates" policy. > > - Twitter has not stated whether there are any additional circumstances > > beyond those two cases in which updates will be silently rejected. > > - Twitter has not stated any plans regarding adding an indicator for > > when a "200 OK" status update has, in fact, been rejected. > > > > I am attempting to compensate for this change by checking the returned > > status ID against the previous highest-seen ID to determine whether the > > status returned with the "200 OK" response is a new one or the user's > > pre-existing status. This seems to work, but does not indicate the > > reason for the silent failure, so I can't report the cause to my users. > > Andy Freeman has mentioned that, in the case of rejection due to > > duplication, this is also unsatisfactory in that it does not allow him > > to identify the original status which was duplicated. > > > > -- > > Dave Sherohman > -- AJ Chen, PhD Chair, Semantic Web SIG, sdforum.org http://web2express.org Palo Alto, CA
[twitter-dev] Re: API 140 character truncation change?
Here are two threads related to this issue. http://groups.google.com/group/twitter-development-talk/browse_thread/thread/cd95ce07be341223/66c66de585383868#66c66de585383868 http://groups.google.com/group/twitter-development-talk/browse_thread/thread/3d6a727892710d5e# It is an inconvenient change, not because they changed it, but because they did not announce that the change was happening. On Oct 21, 5:37 am, Dave Sherohman wrote: > On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote: > > Has anyone else noticed a change in the way that the 140 character > > limit is enforced via the API? I noticed a change sometime between the > > 13th and the 16th that is now causing all my 140+ character posts to > > be rejected by the API. > > Also a side note is that the api is not returning errors, they return > > proper responses however they are the proper response for the current > > status of the account, not the new status that was just attempted to > > be posted. > > My users first reported issues arising from this on the 15th, although I > didn't identify the cause until the 17th, at which point I asked about > it in #Net::Twitter and Marc Mims brought the question here under the > subject line "Bug? Updates > 140 characters return success with prior > update payload". See the discussion under that thread for more on it, > but the overall upshot is: > > - This is an intentional (if poorly-announced) change, not a bug. > - Status updates are known to be getting silently rejected in this > manner both due to exceeding 140 characters and due to violation of > the expanded "no duplicates" policy. > - Twitter has not stated whether there are any additional circumstances > beyond those two cases in which updates will be silently rejected. > - Twitter has not stated any plans regarding adding an indicator for > when a "200 OK" status update has, in fact, been rejected. > > I am attempting to compensate for this change by checking the returned > status ID against the previous highest-seen ID to determine whether the > status returned with the "200 OK" response is a new one or the user's > pre-existing status. This seems to work, but does not indicate the > reason for the silent failure, so I can't report the cause to my users. > Andy Freeman has mentioned that, in the case of rejection due to > duplication, this is also unsatisfactory in that it does not allow him > to identify the original status which was duplicated. > > -- > Dave Sherohman
[twitter-dev] Re: API 140 character truncation change?
On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote: > Has anyone else noticed a change in the way that the 140 character > limit is enforced via the API? I noticed a change sometime between the > 13th and the 16th that is now causing all my 140+ character posts to > be rejected by the API. > Also a side note is that the api is not returning errors, they return > proper responses however they are the proper response for the current > status of the account, not the new status that was just attempted to > be posted. My users first reported issues arising from this on the 15th, although I didn't identify the cause until the 17th, at which point I asked about it in #Net::Twitter and Marc Mims brought the question here under the subject line "Bug? Updates > 140 characters return success with prior update payload". See the discussion under that thread for more on it, but the overall upshot is: - This is an intentional (if poorly-announced) change, not a bug. - Status updates are known to be getting silently rejected in this manner both due to exceeding 140 characters and due to violation of the expanded "no duplicates" policy. - Twitter has not stated whether there are any additional circumstances beyond those two cases in which updates will be silently rejected. - Twitter has not stated any plans regarding adding an indicator for when a "200 OK" status update has, in fact, been rejected. I am attempting to compensate for this change by checking the returned status ID against the previous highest-seen ID to determine whether the status returned with the "200 OK" response is a new one or the user's pre-existing status. This seems to work, but does not indicate the reason for the silent failure, so I can't report the cause to my users. Andy Freeman has mentioned that, in the case of rejection due to duplication, this is also unsatisfactory in that it does not allow him to identify the original status which was duplicated. -- Dave Sherohman
[twitter-dev] Re: API 140 character truncation change?
This is the new intended behaviour from what I have been told. All tweets > 140 in length will be silently ignored. I'm guessing they don't throw an error here yet to not break any existing clients until they have upgraded. Eventually I'm sure we will be some sort of 400 error in the future. For now I'd recommend enforcing the 140 limit in your software and warn the user if it's too long rather than going ahead and posting it. Josh On Tue, Oct 20, 2009 at 9:37 AM, James Tymann wrote: > > Has anyone else noticed a change in the way that the 140 character > limit is enforced via the API? I noticed a change sometime between the > 13th and the 16th that is now causing all my 140+ character posts to > be rejected by the API. As of the 13th and earlier if I posted a 140+ > character message to twitter, the urls would be truncated using > bit.ly, and then if they were still over 140 characters an ellipsis > would be added to the end of the message, and by clicking on the > ellipsis you could see the entirety on the message. I have a service > that posts to twitter, and in the messages it contains links. My > service aims to be under 140 characters once the url(s) are shortened > by twitter, however none of my posts are going through now. > > Also a side note is that the api is not returning errors, they return > proper responses however they are the proper response for the current > status of the account, not the new status that was just attempted to > be posted. > > I am using C# and the Twitterizer API. Has anyone else noticed this, > is it a permanent change? a mistake? I am currently trying to learn > more about why this happened and what my proper response should be. > > Thank you >
