@Amit Shah, I think it depends if the client update is mandatory or not. Let's say the clients are mobile apps, it'd be a bad experience if each time you make a change to your API you're requesting your users to first update their app. It's better to support the previous API and notify the users when a new version is available so that they can download it when they want. But if the client is really using an old version, it's OK to ask them to update...
it works, but not for all cases, in some cases is mandatory to have multiple api version, for example, when a business logic with has a contract with an old app version, both, will work only if they are in the same version.
One question - What are the use cases in which versioning is needed for internal api's? As I understand the API provider has a complete control over its clients so as the API's change, the clients could also be updated. The internal api's are generally used for integrated the backend with frontend (web, mobile etc). When should we think of versioning internal api's?
Lots of reasons actually. * Other teams might have different sets of prioritites or have extreme lack of resources to update. * Doing a coordinated release with breaking change is a logistical nightmare. Do we press "deploy" button simultaneously? What if one of the systems introduced a critical bug in the same commit as the version upgrade? * Mobile apps are not updates by all users simultaneously. Some may be stuck, have issues with app store, old version of the OS etc. That means versioning internal APIs makes sense as soon as you have several systems that are deployed differently. For simple integrations/systems ad-hoc approach might work (e. g. simply having a new endpoint and not removing the old one for some time) but for large, complex APIs the approach from the talk should be the best.
Either query string parameters or a body. A body for a GET request is unexpected by most frameworks/lib/severs/cache/proxy/etc. but it's not forbidden by HTTP. Or even headers
@@MaZe741 Good thing that API are not meant for browsers, then. Your client HTTP lib (whatever the language) or even curl will probably have no problem with it. But it will probably me incorrectly cached or dropped by proxies. That's why people don't do it. Unexpected behavior (even if valid) will always cause trouble when it will meet a component that is stricter than the norm.
@Amit Shah, I think it depends if the client update is mandatory or not. Let's say the clients are mobile apps, it'd be a bad experience if each time you make a change to your API you're requesting your users to first update their app. It's better to support the previous API and notify the users when a new version is available so that they can download it when they want. But if the client is really using an old version, it's OK to ask them to update...
it works, but not for all cases, in some cases is mandatory to have multiple api version, for example, when a business logic with has a contract with an old app version, both, will work only if they are in the same version.
3:08 was that a "breaking" sound effect?
One question - What are the use cases in which versioning is needed for internal api's? As I understand the API provider has a complete control over its clients so as the API's change, the clients could also be updated. The internal api's are generally used for integrated the backend with frontend (web, mobile etc). When should we think of versioning internal api's?
Lots of reasons actually.
* Other teams might have different sets of prioritites or have extreme lack of resources to update.
* Doing a coordinated release with breaking change is a logistical nightmare. Do we press "deploy" button simultaneously? What if one of the systems introduced a critical bug in the same commit as the version upgrade?
* Mobile apps are not updates by all users simultaneously. Some may be stuck, have issues with app store, old version of the OS etc.
That means versioning internal APIs makes sense as soon as you have several systems that are deployed differently. For simple integrations/systems ad-hoc approach might work (e. g. simply having a new endpoint and not removing the old one for some time) but for large, complex APIs the approach from the talk should be the best.
How do you version GET request. Using your approach it has to be a POST only. As in GET request there will be not request body.
Either query string parameters or a body. A body for a GET request is unexpected by most frameworks/lib/severs/cache/proxy/etc. but it's not forbidden by HTTP.
Or even headers
@@shary0 browsers will remove it, its not possible
@@MaZe741 Good thing that API are not meant for browsers, then. Your client HTTP lib (whatever the language) or even curl will probably have no problem with it. But it will probably me incorrectly cached or dropped by proxies. That's why people don't do it. Unexpected behavior (even if valid) will always cause trouble when it will meet a component that is stricter than the norm.
This all is GraphQL queries, but what about REST API.
If any one has the presentation and can share a link please do so. the link at the end of the presentation is broken.
thanks google: www.slideshare.net/nordicapis/versioning-strategy-for-a-complex-internal-api-konstantin-yakushev
Nice idea!
it does not make sense and it is balderdash. you can have adt but use inheritance and polymorphiism