Considering how fast Twitter changes the API I could see there being a new
version every month. If each version had a deprecation length of 4 months
and as soon as a new version was rolled out it immediately get deprecated we
would still have 4-5 versions around at any given time. That sounds like a
lot of overhead on Twitter's part. Just playing devils advocate. :-P


On Fri, Apr 2, 2010 at 09:06, Aral Balkan <> wrote:

> Hear, hear — all for locked down APIs and strict versioning. :) +1
> Aral
> Sent from my iPhone
> On 2 Apr 2010, at 17:02, Isaiah Carew <> wrote:
> A while back I was frustrated with an OS library method that had a well
> known quirk that never got fixed.  When I cornered an engineer at a dev
> conference he told me something profound: Once an API has been released it's
> locked in.  It's being used by tens of thousands of apps and millions of
> users.  Changing the behavior in any way, even to improve it, is likely to
> hurt more than it helps.
> Last night Twitter added a new field to the search results.  I use a
> publicly available JSON parser bolted on to MGTwitterEngine (both popular
> choices, I think), it had an odd trigger for detecting an early end of the
> Results dictionary and trying to fail gracefully.  The new field triggered
> this condition.  In other words, the lib author made a bad assumption.
> Fortunately a very easy bug to find and correct (even at 2am).
> However, it brings me to my point: that the search results *did* change.
>  They are to spec of course, and the JSON lib *should* have been flexible.
>  But it wasn't.  And there was little chance of anyone finding out until it
> affected everyone using my software.  For once, I was grateful that I only
> have a few thousand users.
> But, doesn't every change have this potential?  The potential of triggering
> a well hidden bug in a client that **is** popular and be hugely
> catastrophic.  Am I wrong in thinking this?
> To make this critique a bit more constructive I'd offer some suggestions of
> what I see in other popular API:
> 1.  Every change must be opted into or deprecated away.
> 2.  Deprecation periods need to last for months, not days.
> 3.  Version the endpoints to allow for a one-shot way to know which
> behavior to expect.
> 4.  Document the version differences in the API docs.
> 5.  Add a sandbox for clients to test new endpoints or new changes in a
> safe way.
> isaiah
> <>

Abraham Williams | Community Advocate |
PoseurTech Labs | Projects |
This email is: [ ] shareable [x] ask first [ ] private.

To unsubscribe, reply using "remove me" as the subject.

Reply via email to