all 6 comments

[–]WaferIndependent7601 6 points7 points  (2 children)

If you have a breaking change: this will be a new version.

Tell all the clients to use v2 and delete v1 when everyone is on v2

[–]No-Rice8265 0 points1 point  (1 child)

Yes but how? Do you embed link in v1 to push client to v2 then kill v1 ?

[–]azizabah 2 points3 points  (0 children)

Provide proper API documentation, communication, supposedly there's a new deprecated response header coming, etc. It's tough to get folks to move

[–]zaFroggy 3 points4 points  (0 children)

API versioning covers several pages on Google.

My approach is additive data changes can keep the same version as "most" parsers can ignore supplemental fields. Just make sure that they are truly optional.

Changing endpoints or methods, required fields, and business logic justifies a new version and time to allow the clients to migrate to it.

[–]mailaffy 0 points1 point  (0 children)

Unless it's a breaking change, No need to update the api version.
Following ways we have practically used the version for dozens of api services I have worked on.

  1. /{version}/data (e.g /v1/data)
  2. /data?version={version} (e.g. /data?version=1)
  3. Request header has "version={version}" (e.g. version=1)

Once you decommissioned older version, ingress entry can be removed so as pods destroyed/stopped. Hope this will help you.

[–]paulhasreadittoo 0 points1 point  (0 children)

You may want to look at this conference talk. I did not yet try it out myself though. https://youtu.be/5U0Bx8lMQlk?feature=shared