title: REST and URI Caching
body: <p>As I understand it, using a <a href="http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven" rel="noreferrer">hypertext-driven</a> 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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>There's a lot of information available about caching representations, but what about caching URIs in hypertext-driven RESTful systems?</p>