I am having a set of apis exposed at base/api/v1/end-point1
, base/api/v1/end-point2
, base/api/v1/end-point3
, etc. These are basically v1
apis.
Now we're moving on to expose v2
apis. In this new api version we'll add some new apis, refactor some existing (v1) apis and some apis will remain unaltered.
So my question is should I expose all the unaltered apis of v1 in v2 also ?
Example :
API V1:
api/v1/users - remains unaltered
api/v1/feature1 - will change
other end-points...
API V2:
api/v2/feature1 - refactored feature
api/v2/feature2 - newly added
api/v2/users - should I expose this also ?
I think:
I should not : because it's same
I should : because if it's not exposed then client will need to use different api versions(end-points) for different resources.
What are you doing ? What's your view ? Any reference any best practice resources will be much appreciated.
Let me know if this question is not apt for this platform. I'll happy to ask this at appropriate place.
Yes.
Each version should be independent of other. The rationale is that once a version of API is released to the public, it is going to behave the same till it gets deprecated. This ensures that the API provided are stable and doesn't break with a different response. Also from an end developer perspective who consumes the API, it is clean and doesn't confuse about remembering multiple versions.
We usually have multiple versioning as mentioned in SEMVER docs
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.