0

I'm torn between versioning on the client apps. The scenario in question would be this:

  1. 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/create is no longer supported". But, the client could continue using routes such as /users/find.

  2. 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.

  • I've always seen people do api.whatever.com/v1/users/create, so that when it's updated later they can just switch to the v2 prefix and all of the old stuff continues to work. Of course, if you are working with an API that has already defined api.whatever.com/users/create, you could always just make an exception and start using versions in the URLs for the new ones. – MilkeyMouse Nov 13 '15 at 0:52
  • @AwesomeSauce I think most people use the method you are speaking of, which would also be about equivalent to my 2nd approach mentioned above (if you have to expire a version, return an error for all paths if that expired version is requested, rather than only specific paths). I'm not using versioned paths, but using Accept header with media types for versioning – HelloWorld Nov 13 '15 at 16:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.