this post was submitted on 26 Aug 2023
24 points (100.0% liked)
Experienced Devs
3902 readers
1 users here now
A community for discussion amongst professional software developers.
Posts should be relevant to those well into their careers.
For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:
- Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I don't understand. If you are able to upgrade by just passing a new version number to an API, then the API signature hasn't really changed enough to necessitate any changes on behalf of the user, right? Like, the API function signature hasn't changed?
The kinds of rapid iteration I'm talking about might involve completely removing APIs and making large breaking changes to the API surface itself, requiring user code to be rewritten to some degree.
We’ll of course it depends on the scale of the changes. Depending on how your calling them, the version could be in the url, such as zooms api including /v2/ in the urls. Then you can introduce /v3 with many changes whilst leaving /v2 in place for some amount of time.
If /v3 also means a complete change of database and other underlying infrastructure (eg removing the concept of a zoom meeting), then you’ve got different challenges. Those are probably about overall design, not api.
I'm not really talking about REST APIs. More concerned with code libraries.
The idea doesn't change if it's rest or a code library. The version definition would just go in you requirements.txt or go.mod or whatever instead of a url endpoint.