REST and URI Caching

Question

As I understand it, using a hypertext-driven RESTful Web service, a client is not supposed to know anything about server URI layout except for a couple of well-known entry points. This is supposed to enable the server to control its own URI space and reduce coupling with the client.

When a client for the service sends a successful request to create a new resource, the service responds 201 CREATED and gives the URI at which the new resource can be accessed in the Location header field.

Should a client be allowed to store this URI to enable direct access to the resource in the future and if so for how long? If URIs are cached by the client, this seems to be setting up a situation in which every time the server changes its URI layout, it will need to make sure a permanent redirect gets served when old URIs are accessed. Otherwise the client breaks. Over several years, this system of redirects could get out of hand.

This situation would not appear to have given the server much more control over its URI space than a REST-RPC hybrid approach using URI templates.

There's a lot of information available about caching representations, but what about caching URIs in hypertext-driven RESTful systems?

Answer 1

Remember as Tim Berners-Lee said, "cool URLs don't change". Once the server hands out a URI to the client, it is now the server's job to keep the URI working in the future by (for instance) sending a Moved-Permanently response in case the URI changed and someone requests the old one.

This is actually what encourages many to design opaque URIs, such as based on database ids or timestamps, rather than using some human-readable property of the resource in the URI. Anything that people understand, they will want to change.