This.
I've always thought that the obvious path would be to have unique
error codes that never change. So if there's an auth fail it returns
1234 and 1234 corresponds to a specific message that is called
externally. So we send the error code we're getting and it replies
with the message and a description. So say they decide to change "auth
fail" to "auth has failed" developers see no changes, unless they're
using the twitter error message and then the message changes. So we
have unique error codes that, when requested, return an error message
that can be changed whenever you guys like and has no affect on
developers and their apps. So for debugging we can simply call the
description and error message from the code, but in a live environment
we can build our own error handling based upon the error code, without
having to constantly watch out for changes.
Apologies if that lacks sense, not very good at explaining.
On Sep 15, 9:21 pm, PJB wrote:
> Please also stop willy-nilly changing the error codes and error
> messages. Since your error messages are so often inaccurate, some of
> us have setup special rules to decipher what the errors actually are
> -- when you change the text or code, our rules break.
>
> For example, suspended users are/were getting rate limit warnings when
> trying to authenticate as them. Separately, a new "not authorized"
> message appears for both failed authentication errors as well as
> successfully authenticated users trying friends/ids on blocking
> users. Since the messages and codes are the same, it is hard to
> distinguish between these error types to tell the user what is going
> on. There are about a half-dozen of these ambiguities and bad errors
> that we've accounted for. (Don't get me started on "200: OK" non-
> errors.)
>
> So, after much trial and error, we CAN figure out the actual
> underlying problem based on the action and message you send us. But
> when you suddenly change the error code, or message, it throws our
> rules into disarray.
>
> (Of course, it would be nice if the actual error messages you sent
> were themselves accurate, but for now we're just hoping you can
> CONSISTENTLY send us the same inaccurate errors.)
>
> On Sep 15, 12:29 pm, Alex Payne wrote:
>
> > We're planning on doing just that: communicating more, monitoring the
> > API via a third-party service from a variety of locales, and providing
> > better documentation. We've got more developer support hires lined up,
> > and more.
>
> > Thanks for the list of what you'd like to see, and thanks for bearing with
> > us.
>
> > On Tue, Sep 15, 2009 at 12:13, zippy_monster wrote:
>
> > > On Sep 15, 11:04 am, Alex Payne wrote:
>
> > >> Please understand that the denormalized lists are currently provided
> > >> to developers on a best-effort basis. For the vast majority of Twitter
> > >> applications, this data isn't necessary. A specialized class of
> > >> applications need this data, and we're doing our best to provide it.
>
> > > As a developer, implementation details are mainly a recreational
> > > interest. My primary concern is the end result (does it work? or
> > > not?). Excuses and apologies are nice, but not a substitute for more
> > > explicit testing and communication. So far I've run into two
> > > disruptive changes:
>
> > > - Today, for a brief period, API queries were returning twice the
> > > number of responses they should have. Instead of showing the proper 6
> > > DMs, I was getting 12 back. Oops.
>
> > > - Previously, the way POST + OAuth requests were being handled
> > > changed. The code I was using (MGTwitterEngine + various OAuth hacks)
> > > was sending GET arguments with every request (even POST). For a while
> > > this worked, but in the past few weeks this broke with no warning.
> > > Yeah, that was sloppy client-side code, but the documentation was
> > > silent on this, and certainly the error message (invalid/re-used
> > > nonce) was not terribly helpful as a proper nonce was being generated
> > > each time.
>
> > > Additionally, Internet rumblings about how OAuth was handled lend
> > > credence to the idea that the API just isn't terribly stable... both
> > > from the idea that you're pushing people to use what is officially
> > > considered an experimental API, and that it's being treated as an
> > > experimental API (OAuth specific outages for instance).
>
> > > Or, the current pagination problems. The threads I see here seem to
> > > all be started by API consumers. What's missing from the picture is
> > > an announcement from Twitter that some feature is broken. That smacks
> > > of really poor (well, non-existent) communication.
>
> > > So, yeah, after spending time tracking down the above problems, and
> > > reading general internet rumblings, my gut feeling is that the Twitter
> > > API simply isn't terribly stable. Specifically, I wonder how serious
> > > Twitter is about testing things in a non-production environment. If I
> > > had to p
