Move Fast, Don't Break Your API

http://amberonrails.com/move-fast-dont-break-your-api/

by ewang1 • 12 years ago

119 15 12 years ago

room271• 12 years ago

This is a fascinating article. Some innovative stuff to deal with the difficult problem of how to innovate without breaking existing customers.

Some highlights:

* when a client first makes requests store their version, so that they don't have to worry about it * decouple features from versions, by using 'gates' (allowing for far more versions than would otherwise be possible)

beefsack• 12 years ago

It's an interesting idea but I can't see how it'd work cleanly in practise. The consumer won't even know what version they're using themselves, which makes documentation and API client updates more difficult than it should be.

I don't see why it's so hard to chuck a version in the URL. There's no great need to update the version when adding new features, only when changing existing functionality.

ivanceras• 12 years ago

I think he means, that when a client make a request, the API server will now what version of the API it is calling, then whatever data the api call created/updated, the version of the the API being used will also be stored into the data.

gdb• 12 years ago

(I work at Stripe.)

It's an interesting idea but I can't see how it'd work cleanly in practise. The consumer won't even know what version they're using themselves, which makes documentation and API client updates more difficult than it should be.

To some extent, this is a design goal: most of the time, you should not need to know or care what version of the API you're on (your API's history is pretty irrelevant to a new consumer). Most API consumers just want to test out some calls, make sure they work at the time, and know that they won't break in the future. If you want to discover or set your version, you can do so easily.

I don't see why it's so hard to chuck a version in the URL. There's no great need to update the version when adding new features, only when changing existing functionality.

It'd actually be much easier for us just chuck a version in the URL. But that would comes at the expense of ease for our users.

I think of our approach as making versions be data rather than code. It means that users using standard plugins can often upgrade without having to fork. (We also have many of our client libraries discover properties directly from the API, meaning that they very rarely need upgrading). It also means that new users never have to go and figure out "what's the current version of the API? hm, the guide I'm reading is telling me to use one that's 4 versions out-of-date — I guess I'll copy-paste the code and then modify all the URLs". (If you instead encapsulate the version in your client library, you may as well just make it a database setting.) As a general rule, a code change for a user is much more expensive than frobbing an account setting (given that it's possible to test).

[1] http://docs.aws.amazon.com/Route53/latest/APIReference/API_C...

suzyperplexus• 12 years ago

Amber also did this as a presentation at Heavybit if you're interested in seeing it http://www.heavybit.com/library/developer-technical/video/20...

zzen• 12 years ago

Cool article & design approach. I've really enjoyed the Heavybit talk a couple weeks back, wrote about it today at HB blog: http://blog.heavybit.com/blog/apiary-api-design-versioning-t...

nsondhi• 12 years ago

We also wrote a blog about the talk http://blog.heavybit.com/blog/apiary-api-design-versioning-t...

Very interesting talk!

koopajah2• 12 years ago

Does it also mean that when doing an API client library for stripe you have to handle all this complexity about versionning? Because if someone updates to the latest version of the library but still wants to use the old way of creating a charge (staying on the example where charge would now always be 1$) he would want to be able to do it without having to find an older version of the library that supported this API version.

amfeng• 12 years ago

Hi! OP here.

This actually works out okay for most of our libraries. For the ones that can support it (Ruby, Python, etc), we don't hardcode the properties for any resources and instead generate objects on-the-fly when you make an API request.

In the $1 example, the libraries will just construct a Charge object without the `amount` property, since it wasn't returned in the API response.

You're right that it isn't perfect for other languages, though. We're working on making our versioning story better in our docs, libraries, webhooks, etc. (:

koopajah2• 12 years ago

I understand how you handle it on your end but let's assume I decide to build an API for a language you don't support yet. In a few months when you add new versions of the API where some fields become optional or mandatory, then won't I have to know all this as the library developer and handle each case? Because some of my users would expect to still be able to send the charge amount while others would not.

I'm more thinking in the idea of doing some "pre-validation" in my library to avoid an API call from the client when something is already expected to fail (like missing the amount field right now) which would not fail with a new version of the API. So I would have to adapt to each version to know that this user would require the amount field while another one would not.

100k• 12 years ago

I was at her presentation of this on Wednesday and it was great to get a peek at how Stripe does their API development, since what they've built has been really impressive.

Reading this (or watching the video) will be well worth your time.

capkutay• 12 years ago

I was going to say, 'Move Fast, Don't Break Anything But Your Local Code Branch"...API works too.

Move Fast, Don't Break Your API

Related Stories