5 ms·
Always excited to hear Stripe talking about versioning :D For anyone else who's interested, they've written/talked about this a few times over the years, to f
by ianstormtaylor 9y ago
Always excited to hear Stripe talking about versioning :D
For anyone else who's interested, they've written/talked about this a few times over the years, to fill out the picture:
- http://amberonrails.com/move-fast-dont-break-your-api/ http://amberonrails.com/move-fast-dont-break-your-api/
- https://www.heavybit.com/library/video/move-fast-dont-break-api/ https://www.heavybit.com/library/video/move-fast-dont-break-...
- https://speakerdeck.com/apistrat/api-versioning-at-stripe https://speakerdeck.com/apistrat/api-versioning-at-stripe
- https://brandur.org/api-upgrades https://brandur.org/api-upgrades
- https://news.ycombinator.com/item?id=13708927 https://news.ycombinator.com/item?id=13708927
It sounds like their YAML system has changed to be implemented in code instead, which maybe allows the transforms to be a bit more helpful/encapsulated. If anyone from Stripe is here, it would be awesome to know if that's true and why the switch?
- bkrausz 9y agoI built a lot of the new system at Stripe: the old system would set a flag that was globally accessible inside of an API request. This meant that it was impossible to scope down which changes were relevant to which API methods or resources. Now we can statically introspect into changes. Additionally, devs would need to specify what their changes were independent of where they made the change, which meant that our API reference (which can display warning flags next to changed fields) was missing changes. With the new system we can enforce that the change being made is properly documented, since we know that it's encapsulated inside of the change class itself.