I'm torn between versioning on the client apps. The scenario in question would be this:
Each rote checks it's own API version for the request. So, let's say that there is a breaking change in one route (e.g.
/users/create), but all other routes on the app have not changed (or at least in a breaking manner). So the client could now use all other routes, EXCEPT
/users/create, if they did not upgrade to the latest API.
It would be possible to just return an error message for the route in question and say "Route
/users/createis no longer supported". But, the client could continue using routes such as
Return an error message if any client requests any route with an older version, after the breaking change.
Obviously one wants to keep from having any breaking changes, but inevitably they will happen.
Is it bad practice to do support api versions on a route basis, rather than a whole server request basis?
I can see merits (still giving the client app SOME functionality if they can't upgrade) of doing it, but it becomes more confusing for the client. And possibly the user, say the Android or iOS app now lets the user have half the functionality, but when they try to do certain things (e.g. create a user) they cannot.