Some say that if HATEOAS is followed, there should never be a reason for a client to "know" an API. The assumption is that every link in a resource can be characterized precisely (via link relations, profiles, media types, etc.) enough that automated clients know what they can do and how they should do it. In practice, we're not really to that point yet, but also in practice there is often a human around somewhere to help a client navigate a changed API even if it can't figure that out automatically.
I think I'd agree that automated clients have a ways to go before that works. But sometimes you don't even want anything automated: sometimes the API just needs to change because e.g. the world around it has changed, requirements have changed. A version string in the API seems like a reasonable way to do that.
I think we can agree that there is some level of change at which we should not consider "the world" to have changed. I.e. if previously one could frobnobulate Widgets A, B, and C, and now Widget A has been replaced by Widgets Y and Z, that probably isn't a change to "the world". Only a client ill-conceived enough to maintain its own Widget Catalog would get screwed up by that change. (Don't laugh; this has been done lots of times.) Now suppose that before frobnobulating Widget B, we must first fizzgiggle it. There is a non-empty set of clients that survived the widget update but that will DIAF with the widget-specific-dependency-of-transitive-widget-verb update. So, don't write a Transitive-Widget-Verbs-and-Their-Widget-Specific-Dependencies Catalog into your client either. Et cetera...
Eventually we'll all get to a point at which the generalization must stop. REST advocates think that point is much farther away than is commonly believed. In the case of my dumb example, giving the client developer a version number wouldn't really have helped her avoid a rewrite, because Widget A is no longer available and Widget B must be fizzgiggled before it is frobnobulated. You could imagine that she has enough pull to insist on treating her Widgets exactly as she pleases, but that's not the hypothesis here. (After all in that case she could just have her own entry URI.) It's much better to use media types, link relations, etc. to let the client implicitly learn the information it needs to know every time it needs to know it.
