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

Since one of the principals of REST is that resources are addressable, it seems perfectly acceptable for a client to keep track of the address (URI) for a given resource. Resource URIs should be one of the "well known entry points" you referred to.

Answer 2

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.

Answer 3

Yes the client should be allowed to store the URI. For as long as it wants. As Licky mentioned a smart client can use a Moved-Permanently response to update its bookmarks.

If you think about it, we have the best possible situation. You can change the urls on the server, whilst choosing to still support old clients for as long as we choose, and intelligent clients can effectively auto update themselves to the new urls.

How long you choose to continue to support those old urls is really a decision that needs to be made based on the existing clients and the ease with which they can be maintained.

For me this is a huge improvement over the versioning issues with RPC style interfaces.