3 ms·
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
by michaelchisari 9y ago
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.
- lifeisstillgood 9y agoThis 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 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