Are you referring to for instance a open rest API?
In this case it depends on the consumers of the API and what your preference is (ease of use, semantically correctness). You mostly see either one of the three below.
1. Adding version in the URL (ease of use is high, semantic correctness low)
2. Modifying the Accept header in the request and add the version there (less ease of use, but higher semantically correct since now you are asking the client what version it is requesting)
Accept: application/vnd.yourcustomname.v2+json
3. Adding a custom header (actually not easy to use and not correct)
I think the best strategy is to always try to minimise backward compatibility issues and if you need to do it be clear on when a specific version will become end of life.
------------------------------
Jeroen Van der Laan
Eurofiber Group
------------------------------
Original Message:
Sent: 06-06-2017 16:47
From: Joseph Alexander
Subject: API versioning
How does one manage API versioning and backwards compatibility on a production network, what are the pain points that need greater attention?
------------------------------
Joseph Alexander
Ciena Corporation
------------------------------