据我所知，使用hypertext-driven RESTful Web服务，除了几个众所周知的入口点之外，客户端不应该知道有关服务器URI布局的任何信息。这应该使服务器能够控制自己的URI空间并减少与客户端的耦合。
当服务的客户端发送成功请求以创建新资源时，服务响应201 CREATED并在Location头字段中提供可以访问新资源的URI。
是否允许客户端存储此URI以便将来能够直接访问资源，如果存在多长时间？如果客户端缓存了URI，这似乎就是在设置一种情况，即每次服务器更改其URI布局时，都需要确保在访问旧URI时提供永久重定向。否则客户端会中断。几年来，这种重定向系统可能会失控。
与使用URI模板的REST-RPC混合方法相比，这种情况似乎没有让服务器对其URI空间有更多的控制。
有很多关于缓存表示的信息，但是在超文本驱动的RESTful系统中缓存URI呢？
答案 0 :(得分：6)
请记住Tim Berners-Lee说，“很酷的网址不会改变”。一旦服务器向客户端发出URI，现在服务器的工作就是通过（例如）发送一个Moved-Permanently响应来保持URI工作，以防URI发生变化并且有人请求旧的响应。
这实际上是鼓励许多人设计不透明的URI，例如基于数据库ID或时间戳，而不是在URI中使用资源的某些人类可读属性。任何人都理解的东西，他们都会想要改变。
答案 1 :(得分：2)
是的，应该允许客户端存储URI。只要它想要。正如Licky所说，智能客户端可以使用Moved-Permanently响应来更新其书签。
如果您考虑一下，我们会有最好的情况。您可以更改服务器上的URL，同时选择仍然支持旧客户端，智能客户端可以有效地自动更新自己的新URL。
您选择继续支持这些旧网址的时间实际上是一个需要根据现有客户端以及维护它们的难易程度做出的决定。
对我而言，这是对RPC样式接口的版本控制问题的巨大改进。
答案 2 :(得分：1)
我知道这是一个老问题，但我认为我在这里看到的答案的子组件还没有得到解决。
请记住，您并未从服务器检索资源，但您正在检索资源的REPRESENTATION。资源本身可能具有其主要标识符更改，或者被重新连接，或者其他任何内容，但是在创建资源时返回给客户端的表示可能（或可能不是）独立有效;这完全是情况问题。
例如，考虑一个受审核的内容上传系统;用户可以具有上传内容以供主持人考虑的能力，这可能最终导致内容暴露给更广泛的受众/市场。在初始上传时，服务器可以使用指向（例如）＆＃34; users / {userid} / uploaded / {contentid}＆＃34;的URI进行响应。对于该内容的表示。在某些时候，主持人可能决定将内容推广到首页＆＃34 ;;然后，内容的表示可以在＆＃34; content / {contentid}＆＃34;的URI处获得;这不应该阻止原始上传者访问＆＃34; users / {userid} / uploaded / {contentid}＆＃34 ;;没有什么说需要永久性的重定向，事实上，没有必要进行永久的重定向;如果用户决定要删除内容，他们应该能够对内容执行DELETE;如果用户对他们自己的内容表示进行删除，那么可能会优先考虑上传＆＃34;位置。但是，如果站点的条款表明用户对上传内容的权限被撤销（并非罕见），那么让审核促销流程有效地从用户自己的区域中删除内容可能是有意义的，从而导致＆＃34永久搬家＆＃34;。
它完全取决于具体情况;缓存URI的有效性完全取决于服务器的策略。至少，我认为对无效URI（可能以前有效）的请求应该导致响应（与HATEOAS一致），这可以允许客户端重新发现＆＃34;他们正在寻找的资源（代表）;至少是指向入口点的链接。
答案 3 :(得分：0)
由于REST的一个主要原因是资源是可寻址的，因此客户端可以完全接受跟踪给定资源的地址（URI）。资源URI应该是您提到的“众所周知的入口点”之一。