I really like the rolling versioning approach. Makes a lot of sense.
APIs as infrastructure: future-proofing Stripe with versioning
11–20 of 53 posts
Re: APIs as infrastructure: future-proofing Stripe with versioning
#12I wrote a library that will assist anyone wanting to do something similar for versioning using Django Rest Framework: https://github.com/mrhwick/django-rest-framework-version-tra...
Re: APIs as infrastructure: future-proofing Stripe with versioning
#13Github also versions their API via headers, but uses the `Accept` header instead: https://developer.github.com/v3/media/
Re: APIs as infrastructure: future-proofing Stripe with versioning
#14Github also versions their API via headers, but uses the `Accept` header instead: https://developer.github.com/v3/media/
Nice.
Re: APIs as infrastructure: future-proofing Stripe with versioning
#15This is awesome. As someone who's built many APIs, I have always wondered how Stripe managed all those versions. I knew their code couldn't just be littered with if/thens. This is a really smart way to do it. One question is, over the years, wouldn't you add a lot of overhead to each request in transformation? Or do you have a policy where you expire versions that are more than 2 years old, etc? (skimmed through part…
Assuming that Stripe's userbase grows over time and that their new API versions offer features that are useful to a significant portion of their existing userbase, I would expect the majority of requests at any time to be for a recent API version that needs few (or no) transformations. This is especially likely considering that Stripe provides official client libraries (which are presumably up to date) for a lot of languages.
Stripe probably tracks the relative usage of each API version. If they found a lot of their users were stuck on an old version, that would point to a bigger problem than just some per-request overhead.
Re: APIs as infrastructure: future-proofing Stripe with versioning
#16I think this is one area where GraphQL really excels. It essentially can handle all of this versioning for you (as clients specify EXACTLY what they want) - you just need to make sure that as you evolve your schema that existing fields are left as-is and you only add new fields (not an easy task, but no harder than what you have to do in Stripe's protocol).
Re: APIs as infrastructure: future-proofing Stripe with versioning
#17Brilliant article. Whatever versioning schema that you use, you should at least start with _something_ at the outset of an application IMO
Re: APIs as infrastructure: future-proofing Stripe with versioning
#18I'd love to see more specifics on the documentation automation. Keeping docs straight sounds like the biggest challenge with a system like this.
Re: APIs as infrastructure: future-proofing Stripe with versioning
#19Does anyone know if there's a publicly-available Ruby gem for doing what's described in this blog post - i.e., cascading transformations with a nice DSL? If someone from Stripe reads this, I think you could count on some decent community interest for this framework if you ever consider open-sourcing it.
Re: APIs as infrastructure: future-proofing Stripe with versioning
#20This is awesome. As someone who's built many APIs, I have always wondered how Stripe managed all those versions. I knew their code couldn't just be littered with if/thens. This is a really smart way to do it. One question is, over the years, wouldn't you add a lot of overhead to each request in transformation? Or do you have a policy where you expire versions that are more than 2 years old, etc? (skimmed through part…
All your questions are answered in the article:
- They apply transformations to convert responses from the current version to the previous version, step by step.
- This means the overhead for old versions only applies to consumers of the old version.
- They support all versions going back 6 years.