Thanks API team for implementing the cursoring, really needed it (could you tell!?). I have to go implement that right now.
On Sep 16, 9:24 am, citricsquid <s...@samryan.co.uk> wrote: > 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 <pjbmancun...@gmail.com> 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 <a...@twitter.com> 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 <alex.zep...@gmail.com> > > > wrote: > > > > > On Sep 15, 11:04 am, Alex Payne <a...@twitter.com> 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 propose a solution, it would be to keep a more explicit list > > > > (blog, regular group postings, whatever) of what changes... even if > > > > you think it's insignificant. When something breaks, no matter how > > > > small, a formal announcement would be great. If such a thing exists, > > > > I sure don't know about it. > > > > > The API blog hasn't been updated since July. The third hit on Google > > > > for "twitter api" is a post to this group begging for documentation. > > > > The API changelog is out there, but it too seems like it's not > > > > consistently updated. > > > > -- > > > Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x
