This is a fascinating article. Some innovative stuff to deal with the difficult problem of how to innovate without breaking existing customers.<p>Some highlights:<p>* 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)
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.<p>Reading this (or watching the video) will be well worth your time.
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.
Cool article & design approach. I've really enjoyed the Heavybit talk a couple weeks back, wrote about it today at HB blog: <a href="http://blog.heavybit.com/blog/apiary-api-design-versioning-testing" rel="nofollow">http://blog.heavybit.com/blog/apiary-api-design-versioning-t...</a>
We also wrote a blog about the talk <a href="http://blog.heavybit.com/blog/apiary-api-design-versioning-testing" rel="nofollow">http://blog.heavybit.com/blog/apiary-api-design-versioning-t...</a><p>Very interesting talk!
Amber also did this as a presentation at Heavybit if you're interested in seeing it <a href="http://www.heavybit.com/library/developer-technical/video/2014-09-30-amber-feng" rel="nofollow">http://www.heavybit.com/library/developer-technical/video/20...</a>