To begin with, the term REST has unfortunately been hijacked to the point where it’s hard to know what someone might be referring to when they use it. I am going to assume we’re talking about REST as Roy Fielding meant it when he coined the acronym. …

I think in the situation you describe using URIs as the IDs is really compelling. The redirection capability of HTTP can be leveraged to provide excellent forward compatibility.

If your future URI revamp is so simple that the clients would be able to handle, you could implement a simple mod_rewrite rule on the server and not have to mess with the clients at all. If however you ever need to revamp the URI patterns is some really fundamental way you can create, as part of the migration, a mapping between the old URIs and the equivalent new URIs.

That combined with a client that respects the redirect type and you have a really scalable system. By that I mean, any client that stores URIs should updated them if it ever gets a permanent redirect when requesting that URI. If the client has some URI and a year later makes a GET request against it and receives a 301 “Moved Permanently”, it would updated that replace the old URI with the new URI in it’s internal storage.

These mechanisms mean that you do not need a non-standard, or out-of-band, way to communicate URI pattern changes to the clients.

If we change our root URI, all the links bust. If our clients use “base URI + id” to construct URIs, then when we change, at least they just have to change the base URI instead of having to fix up a billion stored links (since the stored IDs would not have changed, though the URI did). [BTW, we're looking at using something similar to "ark" to resolve broken links from the ids using a namespace at the beginning of the and a "resolver" service].

When the clients are only using URIs temporarily, then it makes sense for them to get those full URIs from the server on the fly. But if they are storing them, then I’m still struggling with the best approach.