Josh
> 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
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
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