I personally prefer this approach - certainly if the changes you're making are only to the representation of your resources, then (assuming they can't be made p

I personally prefer this approach - certainly if the changes you're making are only to the representation of your resources, then (assuming they can't be made purely additively, i.e. without breaking existing clients) simply making a new content type available seems the natural way to go. If it's of interest, I wrote a couple of articles about how we implemented exactly this sort of versioning in Rails for our app's API: http://techblog.tribesports.com/blog/2011/09/24/versioning-the-tribesports-api http://techblog.tribesports.com/blog/2011/09/24/versioning-t... http://techblog.tribesports.com/blog/2011/09/24/separating-api-logic-with-decorators http://techblog.tribesports.com/blog/2011/09/24/separating-a... I think these demonstrate the advantages of content negotiation as a versioning mechanism. To introduce a new API representation, we simply have to define a new set of decorators for our exposed resources, define a new MIME type and we're set. No monkeying with our routing, no messing around in controllers; a view-level change entails only view-level code alterations.