Have to see its documentation. Otherwise, I assume it is 1 API (/endpoint/), 2 different routing (/api/v2, and /api/v1), 1 version difference (v2).
Should not be an issue since all 4 URIs are unique and you have the freedom to roll out the following updates:
- API pathing improvements (non-backward compatible and backward compatible changes)
- input data schema changes
- new API can has its own cache without interfering with existing API ones
- output data schema changes
- can roll out non-interfering deprecation and removal.
What I can see is that using subdomain method assumes you have easy access to DNS administration to roll out API versioning updates. For small project or you’re the DNS administrator, this would not be an issue. Otherwise, you need to through some red-tapes from network dept.
The /vX/ pathing method allows you to work on the same network and DNS settings so 1 less dept to visit when you roll out API updates every single time.
Another matter, assuming you’re serving from 1 origin server, is that you need to configure your server to be multi-facing for serving multiple subdomains. However, if each version has its own origin server clusters, then subdomain makes sense to separate both v1 and v2 servers.
There are many ways of versioning API. The most important part is documentation + deprecation notice, built-in deprecation warning, communications with your customers, and grace period.