APIs as infrastructure: future-proofing Stripe with versioning

Re:APIs as infrastructure: future-proofing Stripe with versi... by michaelchisari on Wednesday August 16, 2017 @12:53AM (#15025023)

Maybe we're talking about the same thing, but basically, the way I see it is this:

1. Request for 2.5 comes in

2. Version 2.5 calls v2.6, takes the data, and transforms it into 2.5.

3. Since a 2.5 response shouldn't have a zipcode field, it's dropped from 2.6 before the 2.5 response is returned.

[ Parent | on HN ]

Re:APIs as infrastructure: future-proofing Stripe with versi... by lifeisstillgood on Wednesday August 16, 2017 @06:06AM (#15026270)

This kind of implies always have 2.5 running as front end code. I would rather have my latest code running (especially as it implies 2.4,2.3,,,1.3) and have that spin up the 2.5 munger code as needed. But yes I think it's more or less the same thing

Interestingly looking at stripe changelog https://stripe.com/docs/upgrades#api-changelog they still do breaking code changes every month or two so despite the effort and with a smallish api they break a lot of contracts.

The odd thing is that they keep a different api version for each customer, tagged at customers settings, so I suspect your approach (spin up api based on incoming version) might work better - but boy I think they may be in a lot of pain trying to maintain that backwards compatibility

[ Parent | on HN ]