A general status update from Twitter's API Team

[Alex Payne]

Hi all,

Just wanted to give you an update on what's going on Twitter API land.

Firstly, my colleague on the API Team, Matt Sanford (@mzsanford), is
in town from Seattle and working from the Twitter offices. We're
trying to make the most of this in-person time to clear out
administrivia and plan the next several weeks of work.

We've just finished cleaning up the list of API issues and enhancement
requests (http://code.google.com/p/twitter-api/issues/list). We've
closed, updated, re-prioritized, and generally attended to all tickets
in the system. We have a number of fixes that are waiting on other
parts of the Twitter engineering team to ship, and we've tried to
clearly note which tickets aren't going to be dealt with until the
next major release of the API.

Just yesterday, Matt finished working with our Operations team to move
Twitter Search to Twitter's data center. The Search API should now
return results more quickly, and we believe that we've increased our
queries per second (QPS) capacity as well.

Additionally, Matt has been working with our User Experience (UX) team
on a beta of OAuth support. The UX component of this work is almost
complete, and we should be ready for our first deploy in the next week
or ten days. The only potential blocker to this launch is the
database schema changes it entails, which may be delayed by our
Operations team as part of a broader set of database work.

Having completed performance tests to our satisfaction, a colleague of
ours has been testing our HTTP-based firehose solution for correctness
and stability. So far he's uncovered no issues, and we should be
starting a beta period with this service in a matter of days.
Apologies for not having the beta going by Thanksgiving, but hopefully
this additional testing will mean fewer issues and a reduced
time-to-production.

Our next major priority remains the rewrite of the Twitter API, which
encompasses a variety of backend and frontend changes. We were hoping
to have much of this work completed by the end of the year, and while
I believe it'll be underway, I don't expect that it will be complete
until early next year.

If you have any questions about our priorities and projects, please
let us know. Thanks!

--
Alex Payne - API Lead, Twitter, Inc.
http://twitter.com/al3x

[Chad Etzel]

Thanks for the update!  For those of us doing current development with the API, will the current version be kept around for a while (as a legacy version I guess) so that we may continue development as the new API is being rolled out?  Or will it be a cut-over situation when the new API is released?  I understand that eventually the current API version will be retired... but looking for guidance in the short-term.

Thanks,
-Chad

[Alex Payne]

We'll keep the current version running for a stretch (probably six
months tops) as developers transition over to the new version of the
API.

[Christopher St John]

On Tue, Dec 2, 2008 at 2:27 PM, Alex Payne <al...@twitter.com> wrote:
>
> Additionally, Matt has been working with our User Experience (UX) team
> on a beta of OAuth support. The UX component of this work is almost
> complete, and we should be ready for our first deploy in the next week
> or ten days.
>

Nifty.

Anything y'all can share about the thinking behind your OAuth UX
decisions would be very helpful (not just how it ends up looking, but
the sorts of things that were of concern, differerent options you
considered, etc). That stuff's pure gold for others facing similar
sorts of decisions. Not totally on topic, I'm just saying...

-cks

--
Christopher St. John
http://artofsystems.blogspot.com

[Alex Payne]

Sure, I'll talk to the UX folks about writing some of that up. OAuth
is still in its early stages, and it seems most every organization
that implements it ends up taking some slightly different paths.

--

[dean.j.robinson]

The rewrite of the api has been on the cards for a while, and I've
kind of avoided doing any major work on Hahlo until I knew what was
happening, however it got the better of me last weekend and I began
work on Hahlo 4 which itself is a complete re-write.

Given that its a re-write how much do you see it changing as far as
how developers access it, ie. will the json,xml etc feeds still be the
same, will there be new/different parameters, or is the whole thing
just going to be completely new/shiny/fantastic?

And even though I do very much like the authentication system I wrote
on the weekend, I might start to investigate OAuth in preparation for
its appearance.

On Dec 3, 9:31 am, "Alex Payne" <a...@twitter.com> wrote:
> Sure, I'll talk to the UX folks about writing some of that up.  OAuth
> is still in its early stages, and it seems most every organization
> that implements it ends up taking some slightly different paths.
>

> On Tue, Dec 2, 2008 at 13:03, Christopher St John <ckstj...@gmail.com> wrote:

[Alex Payne]

The main thing that's changing with the new release of the API is the
URL scheme. We're cleaning things up, moving things around, making
the whole thing more RESTful. I'll confer with @mzsanford and see
about sharing our proposed set of URLs/methods.

Generally, though, we're still the same service and we've still got
the same data to share with API clients, so the actual response
formats themselves should change very little, save some new attributes
popping up. Our main goal is moving the API onto a high-performance
app server and optimizing such that we no longer have to burden all
but the most aggressive clients with rate limiting.

[Damon C]

Hi Alex,

Thanks for the updates - one of the things I noticed is that the
"archive" API method was marked as wontfix. I was wondering what this
means for the future of accessing our Twitter history?

Is this just something where we won't be able to export it in one
shot, but still have access to the history through successive API
calls?

Thanks,

dacort

[Alex Payne]

Yup, until some other under-the-hood stuff changes, we can't really
hand out a user's archive in a single request/response in a timely and
database-friendly fashion. You'll still have to page through to get a
user's full archive, but with effectively non-existent rate limits,
this should be much easier.